Hi Nice, sounds like a very good thing from an operator's perspective.
Cheers, -- Chris Jones > On 22 Aug 2014, at 08:44, Steve Kowalik <ste...@wedontsleep.org> wrote: > >> On 22/08/14 17:35, Chris Jones wrote: >> 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 :) > > If the master nodes list changes, because say you add a second NIC, and up > the amount of RAM for a few of your nodes, we then want to update those > details in the baremetal service, rather than skipping those nodes since they > are already registered. > >> Cheers, >> -- >> 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 >>> OpenStackfirstname.lastname@example.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStackemail@example.com >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > -- > Steve > In the beginning was the word, and the word was content-type: text/plain > > _______________________________________________ > OpenStack-dev mailing list > OpenStackfirstname.lastname@example.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev