Bug 1212516
Summary: | Do not remove <action> tags under <vm> added by ccs | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Radek Steiger <rsteiger> |
Component: | luci | Assignee: | Ryan McCabe <rmccabe> |
Status: | CLOSED WONTFIX | QA Contact: | cluster-qe <cluster-qe> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 6.7 | CC: | cfeist, cluster-maint, cluster-qe, fdinitto, jpokorny, jruemker, mkelly, rmccabe, rsteiger |
Target Milestone: | rc | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | 1079032 | Environment: | |
Last Closed: | 2017-12-06 13:03:30 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 1079032 | ||
Bug Blocks: |
Description
Radek Steiger
2015-04-16 14:41:10 UTC
Frankly its a bit problematic that vm takes the approach of enforcing its op stop timeout internally. With all of our other resource agents (that I'm aware of, at least; perhaps another behaves like vm that I haven't seen), rgmanager is responsible for monitoring the length of time the op is taking and enforcing it if configured to do so. Since __enforce_timeouts defaults to 0, typically that achieves what the reporter was looking for: waiting indefinitely. However vm seems to take a different approach and watch that timeout internally, then take action regardless of whether timeouts are enforced or not. This deviates from typical expected behavior, and as was stated, now creates a need for additional tooling to ensure the necessary parameters can be configured. It creates a problem too, in that you can't easily just say wait as long as you need to, other than by setting a crazy-high timeout value. Looking at this logically, it would seem ideal to stay consistent with other agents and let the administrator decide whether they want timeouts enforced or not. But considering where we are in RHEL 6 and considering from a customer perspective, it seems like we should probably leave the agent alone since its clearly been this way for some time. And I guess in that case, we should probably make it easier for users to tune these settings through Conga as was requested. I don't have any customer cases asking for this, so I'm merely just commenting as I was passing by on the problem of vm implementing its own timeout handling. Can I get the rational behind WONTFIX? (In reply to digimer from comment #4) > Can I get the rational behind WONTFIX? So the wontfix was regarding supporting adding them via luci. The rationale was if it needed to be done, it would be done via ccs. I have renamed and reopened the bug for luci to clarify what needs to be done there. OK, thanks. Digimer, better overview of existing actions than nothing: [bug 1173942] That being said, we will ensure no <action> stanza already configured will get accidentally dropped on configuration round trip through luci. Red Hat Enterprise Linux 6 is in the Production 3 Phase. During the Production 3 Phase, Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available. The official life cycle policy can be reviewed here: http://redhat.com/rhel/lifecycle This issue does not meet the inclusion criteria for the Production 3 Phase and will be marked as CLOSED/WONTFIX. If this remains a critical requirement, please contact Red Hat Customer Support to request a re-evaluation of the issue, citing a clear business justification. Note that a strong business justification will be required for re-evaluation. Red Hat Customer Support can be contacted via the Red Hat Customer Portal at the following URL: https://access.redhat.com/ |