Re: [openstack-dev] [TripleO][Ironic] Unique way to get a registered machine?
On Aug 22, 2014 12:48 AM, 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? You should get a clear error when attempting to add a port with a preexisting MAC. However, at this point, a new node has already been created (this won't fail since it includes no unique info). When catching the duplicate MAC error, you should delete the just-created node. 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. If you want to update information about a node, you must have that nodes UUID, whether cached or retrieved on-demand. You can retrieve this by searching for a port with a known MAC to determine which node is associated with that port. You will have a problem updating the existing NIC(s) if you don't cache the UUID, as MAC address is currently the only other uniquely identifying data point for a node. -Devananda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Ironic] Unique way to get a registered machine?
Woops, meant to respond to this in the email I just sent... On Aug 21, 2014 11:35 PM, Steve Kowalik ste...@wedontsleep.org wrote: 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? pm_address is cruft on the old nova API, and was replaced with driver_info in ironic. Node driver_info is presumably also unique, but the format varies between drivers; uniqueness is not enforced, nor is it searchable in the REST API. In some cases, there are half a dozen data points contained in driver_info (eg, for double bridged IPMI in the case of moonshot) which collectively inform the driver how to connect to and manage that node. -Devananda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [TripleO][Ironic] Unique way to get a registered machine?
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
Re: [openstack-dev] [TripleO][Ironic] Unique way to get a registered machine?
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 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
Re: [openstack-dev] [TripleO][Ironic] Unique way to get a registered machine?
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
Re: [openstack-dev] [TripleO][Ironic] Unique way to get a registered machine?
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
Re: [openstack-dev] [TripleO][Ironic] Unique way to get a registered machine?
Excerpts from Steve Kowalik's message of 2014-08-22 06:32:04 +: 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
