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: | |||
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
|
Using qpid-tool against mrg31: Calling the SetLimit method returns OK (0) - {} However, even after call the Reconfig method, a subsequent call to GetLimits does not show that the limit has been set. Here is a snippet from my qpid-tool session: qpid: list negotiator Object Summary: ID Created Destroyed Index ===================================================== 6707 15:03:45 - mrg27.lab.bos.redhat.com qpid: call 6707 GetLimits OK (0) - {u'Limits': {}} qpid: call 6707 SetLimit a 2 qpid: OK (0) - {} qpid: call 6707 Reconfig qpid: OK (0) - {} qpid: call 6707 GetLimits qpid: OK (0) - {u'Limits': {}}