Bug 796406
| Summary: | wallaby doesn't recognize node config change when group deleted | ||
|---|---|---|---|
| Product: | Red Hat Enterprise MRG | Reporter: | Robert Rati <rrati> |
| Component: | wallaby | Assignee: | Will Benton <willb> |
| Status: | CLOSED ERRATA | QA Contact: | Tomas Rusnak <trusnak> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | medium | ||
| Version: | Development | CC: | iboverma, ltoscano, matt, mkudlej, trusnak, willb |
| Target Milestone: | 2.3 | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | wallaby-0.16.1-1 | Doc Type: | Bug Fix |
| Doc Text: |
C: In prior versions of Wallaby, deleting a group may not have caused nodes that were members of that group to receive updated configurations (if there were no other changes to those nodes between activations).
C: As a result, nodes may have had spurious configurations when the only change to their configuration before an activation is by virtue of one of the groups they are a member of being deleted.
F: Wallaby now handles group deletion by adding member nodes of the deleted group to its internal list of changed nodes, which are due to have recalculated configurations at the next activation.
R: Deleting groups should thus have the expected effect on future configurations of their member nodes.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-03-06 18:41:49 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: | |||
This is fixed upstream and will be in an upcoming package. The problem was that nodes that were members of a deleted group were not added to the dirty list; they are now.
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
New Contents:
C: In prior versions of Wallaby, deleting a group may not have caused nodes that were members of that group to receive updated configurations (if there were no other changes to those nodes between activations).
C: As a result, nodes may have had spurious configurations when the only change to their configuration before an activation is by virtue of one of the groups they are a member of being deleted.
F: Wallaby now handles group deletion by adding member nodes of the deleted group to its internal list of changed nodes, which are due to have recalculated configurations at the next activation.
R: Deleting groups should thus have the expected effect on future configurations of their member nodes.
Reproduced with:
wallaby-0.12.5-1.el5
irb(main):001:0> node = Wallaby::store.getNode("test")
=> <Mrg::Grid::ConfigClient::Node: test>
irb(main):002:0> ver = node.getConfig({})["WALLABY_CONFIG_VERSION"]
=> "1354005195383243"
irb(main):003:0> node.getConfig({}).inspect
=> "{\"COLLECTOR_DEBUG\"=>\"D_FULLDEBUG | D_COMMAND\", \"WALLABY_CONFIG_VERSION\"=>\"1354005195383243\"}"
irb(main):004:0> ver = node.getConfig({})["WALLABY_CONFIG_VERSION"]
Retested with:
wallaby-0.16.1-2
# wallaby console
Console Connection Established...
irb(main):001:0> node = Wallaby::store.getNode("test")
=> <Mrg::Grid::ConfigClient::Node: test>
irb(main):002:0> ver = node.getConfig({})["WALLABY_CONFIG_VERSION"]
=> "1352821921610405"
# wallaby remove-group group1
Console Connection Established...
Removing the following group: group1
# wallaby activate
Console Connection Established...
# wallaby console
Console Connection Established...
irb(main):001:0> node = Wallaby::store.getNode("test")
=> <Mrg::Grid::ConfigClient::Node: test>
irb(main):002:0> ver = node.getConfig({})["WALLABY_CONFIG_VERSION"]
=> "1352821996190495"
irb(main):003:0> node.getConfig({}).inspect
=> "{\"STARTD_LOG\"=>\"$(LOG)/StartLog\", \"MASTER\"=>\"$(SBIN)/condor_master\", \"DAEMON_LIST\"=>\"STARTD, MASTER\", \"CONTINUE,
....
\"CONDOR_DEVELOPERS\"=>\"NONE\", \"COLLECTOR_NAME\"=>\"\", \"ALLOW_READ\"=>\"*\"}"
>>> VERIFIED
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2013-0564.html |
Description of problem: If a group is deleted that has configuration parameters attached to it then nodes part of that group should see their configurations changed upon activation. This is not the case. When a group is deleted, wallaby does not recognize that a node's configuration has changed and no update events are sent out. Version-Release number of selected component (if applicable): wallaby-0.12.4-1.el5 How reproducible: 100% Steps to Reproduce: 1. wallaby add-node test 2. wallaby add-group group1 3. wallaby add-param param1 4. wallaby add-params-to-group group1 param1=value 5. wallaby add-node-memberships test group1 6. wallaby activate 7. wallaby console irb(main):001:0> node = Wallaby::store.getNode("test") irb(main):002:0> ver = node.getConfig({})["WALLABY_CONFIG_VERSION"] irb(main):003:0> puts ver 1329961976054791 8. wallaby remove-group group1 9. wallaby activate 10. wallaby console irb(main):001:0> node = Wallaby::store.getNode("test") irb(main):002:0> ver = node.getConfig({})["WALLABY_CONFIG_VERSION"] irb(main):003:0> puts ver 1329961976054791 irb(main):004:0> node.getConfig({}).inspect -> Notice param1 is not part of the config Actual results: Activation after removal of node did not result in a new WALLABY_CONFIG_VERSIOn Expected results: Activation after removal of node should result in a new WALLABY_CONFIG_VERSIOn Additional info: