When register-nodes blows up, is the error we get from Ironic sufficiently 
unique that we can just consume it and move on?

I'm all for making the API more powerful wrt inspecting the current setup, but 
I also like idempotency :)

Chris Jones

> On 22 Aug 2014, at 07:32, Steve Kowalik <ste...@wedontsleep.org> wrote:
> Hi,
>    TripleO has a bridging script we use to register nodes with a baremetal 
> service (eg: Ironic or Nova-bm), called "register-nodes", which given a list 
> of node descriptions (in JSON), will register them with the appropriate 
> baremetal service.
>    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.
>    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?
> Cheers,
> -- 
>                                        Steve
> "Stop breathing down my neck!"
> "My breathing is merely a simulation."
> "So is my neck! Stop it anyway."
>         - EMH vs EMH, USS Prometheus
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

OpenStack-dev mailing list

Reply via email to