Open Stack

Excerpts from Steve Kowalik's message of 2014-08-22 06:32:04 +0000:
>     At the moment, if you run register-nodes a second time with the same 
> list of nodes, it will happily try and register them and then blow up 
> when Ironic or Nova-bm returns an error. If operators are going to 
> update their master list of nodes to add or remove machines and then run 
> register-nodes again, we need a way to skip registering nodes that are 
> already -- except that I don't really want to extract out the UUID of 
> the registered nodes, because that puts an onus on the operators to make 
> sure that the UUID is listed in the master list, and that would be mean 
> requiring manual data entry, or some way to get that data back out in 
> the tool they use to manage their master list, which may not even have 
> an API. Because our intent is for this bridge between an operators 
> master list, and a baremetal service, the intent is for this to run 
> again and again when changes happen.

I dont understand why inputting the UUID into the master list requires
manual entry? Why cant we, on insertion, also insert the UUID into the
nodes list? One potential downside is that operators cannot fully regen
the nodes list when editing it but have to 'merge in' changes but IMO
this is a good enough start and preferrable to some non-straightforward
implicit behavior done by our own routine.

>     This means we need a way to uniquely identify the machines in the list 
> so we can tell if they are already registered.
> 
>     For the pxe_ssh driver, this means the set of MAC addresses must intersect.
> 
>     For other drivers, we think that the pm_address for each machine will 
> be unique. Would it be possible add some advice to that effect to 
> Ironic's driver API?

Building off my previous comment - If we really want to provide an
implicit updating mechanism so operators can re-gen node lists in
entirety then why not build it as a new processing stage? Im thinking:

1) gen list of just_nodes.json
2) run update_nodes to update nodes.json containing new data and old
UUIDS where applicable
3) pass nodes.json into register nodes

Your proposal of auto detecting updated nodes would live purely in the
update_nodes script but operators could elect to skip this if their node
generation tooling supports it.

- Greg