Open Stack

Hi

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 :)

Cheers,
--
Chris Jones

> On 22 Aug 2014, at 07:32, Steve Kowalik <steven at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev