<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial;font-size:10.5pt" ><div dir="ltr" >I was at the ironic group mgmt design session at the summit (https://etherpad.openstack.org/p/summit-mitaka-ironic-group-management), and didn't get a chance to share my thoughts, so i thought i'd do it here.  I worked on the open source cluster management tool called xCAT (http://xcat.org/) which focusses on hw mgmt and OS deployment.  It has supported group operations for a long time, and this is the approach it takes:  it uses tags like ironic is planning to use for arbitrary node groups.  But to take advantage of vendor hw that manages multiple nodes, xcat doesn't use that to define group membership (as was suggested at the ironic design session).  Instead, every node has a reference in its db entry to what xcat calls its hw control point.  For stand-alone svrs this is just the ipmi info of its bmc, but for nodes that are in some kind of chassis, this is the login info of the chassis controller.  Then for all group operations in xcat, it first preprocesses the node list and groups nodes that have the same hw control point and sends that subset list of nodes to that hw control point.  This decouples the concept of what groups a node is a member of from what controller can do operations against that node.  This way group operations can be done across an arbitrary list of nodes (regardless of what chassis they are in) and at the same time exploit the efficiencies of a chassis manager where available.</div>
<div dir="ltr" > </div>
<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial;font-size:10.5pt" ><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial;font-size:10.5pt" ><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial;font-size:10.5pt" ><div dir="ltr" ><font face="Default Sans Serif,Verdana,Arial,Helvetica,sans-serif" size="2" >Bruce Potter STSM, Cloud Innovation Architect, IBM, Poughkeepsie, NY<br>Email: bp@us.ibm.com</font></div></div></div></div></div><BR>