Bug 611828
Summary: | SetLimit method call on NegotiatorObject should check if limits can be applied | ||
---|---|---|---|
Product: | Red Hat Enterprise MRG | Reporter: | Ernie <eallen> |
Component: | condor-qmf | Assignee: | Matthew Farrellee <matt> |
Status: | CLOSED ERRATA | QA Contact: | Tomas Rusnak <trusnak> |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | 1.0 | CC: | iboverma, jross, matt, mkudlej, pmackinn, trusnak |
Target Milestone: | 2.0 | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | condor-7.5.6-0.2 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2011-06-27 15:30:54 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Ernie
2010-07-06 15:20:20 UTC
GetLimits only returns information about limits that are in use. In the absence of jobs, the output above is expected. RFE for a future release...maybe check if limits can be applied and return appropriate code if possible? As of 7.5.6-0.1, SetLimit works. It will validate the limit name, e.g. qpid: call 187 SetLimit sleep-1234 4 Invalid name for group/user - alphanumeric, underscore and dot characters only (65538) - {} It also also validate if ENABLE_RUNTIME_CONFIG is TRUE, e.g. qpid: call 187 SetLimit sleep 4 Runtime configuration changes disabled (65537) - {} GetLimits in 7.5.6-0.1 is broken. It is fixed upstream for the next build. diff --git a/src/condor_contrib/mgmt/qmf/plugins/NegotiatorObject.cpp b/src/condor_contrib/mgmt/qmf/plugins/N index 0ff73ab..78baa6c 100644 --- a/src/condor_contrib/mgmt/qmf/plugins/NegotiatorObject.cpp +++ b/src/condor_contrib/mgmt/qmf/plugins/NegotiatorObject.cpp @@ -150,9 +150,10 @@ NegotiatorObject::GetLimits(Variant::Map &limits, std::string &/*text*/) // ConcurrencyLimit.y = <y's current usage> matchMaker.getAccountant().ReportLimits(&limitAttrs); + limitAttrs.Delete(ATTR_CURRENT_TIME); // compat_classad insists on adding this limitAttrs.ResetExpr(); const char* attr_name; - while (!limitAttrs.NextExpr(attr_name,expr)) { + while (limitAttrs.NextExpr(attr_name,expr)) { Variant::Map limit; std::string name = attr_name; Tested on supported archs: x86,x86_64/RHEL5,RHEL6 with: condor-7.6.1-0.1.el6.x86_64 ENABLE_RUNTIME_CONFIG is TRUE qpid: call 108 SetLimit sleep-1234 4 qpid: invalid conversion: Cannot convert from int64 to double (qpid/types/Variant.cpp:473) (7) - {} qpid: call 108 SetLimit sleep-1234 4.0 qpid: Invalid name for group/user - alphanumeric, underscore, @ and dot characters only (65538) - {} The value "4" could be converted into double, from my point of view. If I used "4.0" as a value, the validation works as expected. Please, could you check why the int64 cannot be converted into double? "qpid: invalid conversion: Cannot convert from int64 to double (qpid/types/Variant.cpp:473) (7) - {}" is coming from qpid-tool. Please file a new bug against the management component. This is similar to bug 693847. Retested on x86_64/RHEL6 with: $CondorVersion: 7.6.1 Apr 27 2011 BuildID: RH-7.6.1-0.4.el6 $ $CondorPlatform: X86_64-RedHat_6.0 $ Config: CONCURRENCY_LIMIT_DEFAULT = 1 Y_LIMIT = 2 # echo -e "cmd=/bin/sleep\nargs=1h\nconcurrency_limits=Y\nqueue" | sudo -u test condor_submit Submitting job(s). 1 job(s) submitted to cluster 13. qpid: list negotiator Object Summary: ID Created Destroyed Index ===================================================================== 183 14:14:17 - hostname qpid: call 183 GetLimits qpid: OK (0) - {u'Limits': {u'y': {u'CURRENT': 1.0, u'MAX': 2308032.0}}} qpid: call 183 SetLimits Y 3 qpid: call 183 Reconfig qpid: OK (0) - {} qpid: call 183 GetLimits qpid: OK (0) - {u'Limits': {u'y': {u'CURRENT': 1.0, u'MAX': 2.0}}} The limit seems to be same and was not set by SetLimit. Also the initial limit seems to be 2308032.0 instead of requested 2.0. Is this expected behavior, or I doesn't interpret it correctly? You didn't condor_reconfig/restart after you added the config. SetLimits isn't a valid call, though qpid-tool didn't tell you. The call to Reconfig actaully applied your configuration, which is why you then saw the proper MAX. Try: call 123 Reconfig call 123 GetLimits call 123 SetLimit Y 3 call 123 Reconfig call 123 GetLimits Thanks Matt! Now it's working as expected.
Retested over all supported archs x86,x86_64/RHEL5,RHEL6:
qpid: call 177 Reconfig
qpid: OK (0) - {}
qpid: call 177 GetLimits
qpid: OK (0) - {u'Limits': {u'y': {u'CURRENT': 0.0, u'MAX': 2.0}}}
qpid: call 177 SetLimit Y 3.0
qpid: OK (0) - {}
qpid: call 177 Reconfig
qpid: OK (0) - {}
qpid: call 177 GetLimits
qpid: OK (0) - {u'Limits': {u'y': {u'CURRENT': 0.0, u'MAX': 3.0}}}
qpid:
SetLimit works as expected.
>>> VERIFIED
|