Bug 796406 - wallaby doesn't recognize node config change when group deleted
Summary: wallaby doesn't recognize node config change when group deleted
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: wallaby
Version: Development
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: 2.3
: ---
Assignee: Will Benton
QA Contact: Tomas Rusnak
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-02-22 20:10 UTC by Robert Rati
Modified: 2013-03-06 18:41 UTC (History)
6 users (show)

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.
Clone Of:
Environment:
Last Closed: 2013-03-06 18:41:49 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2013:0564 0 normal SHIPPED_LIVE Low: Red Hat Enterprise MRG Grid 2.3 security update 2013-03-06 23:37:09 UTC

Description Robert Rati 2012-02-22 20:10:53 UTC
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:

Comment 2 Will Benton 2012-02-23 15:04:17 UTC
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.

Comment 3 Will Benton 2012-02-23 15:10:15 UTC
    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.

Comment 5 Tomas Rusnak 2012-11-27 14:34:01 UTC
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

Comment 7 errata-xmlrpc 2013-03-06 18:41:49 UTC
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


Note You need to log in before you can comment on or make changes to this bug.