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
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> 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
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to