Re: [openstack-dev] [Ironic] Nodeless Vendor Passthru API
On Tue, Mar 25, 2014 at 6:56 AM, Lucas Alvares Gomes wrote: > > Hi Russell, > > Ironic allows drivers to expose a "vendor passthru" API on a Node. This >> basically serves two purposes: >> >> 1. Allows drivers to expose functionality that hasn't yet been >> standardized in the Ironic API. For example, the Seamicro driver exposes >> "attach_volume", "set_boot_device" and "set_node_vlan_id" passthru methods. >> 2. Vendor passthru is also used by the PXE deploy driver as an internal >> RPC callback mechanism. The deploy ramdisk makes calls to the passthru API >> to signal for a deployment to continue once a server has booted. >> >> For the purposes of this discussion I want to focus on case #2. Case #1 >> is certainly worth a separate discussion - we started this in >> #openstack-ironic on Friday. >> >> In the new agent we are working on, we want to be able to look up what >> node the agent is running on, and eventually to be able to register a new >> node automatically. We will perform an inventory of the server and submit >> that to Ironic, where it can be used to map the agent to an existing Node >> or to create a new one. Once the agent knows what node it is on, it will >> check in with a passthru API much like that used by the PXE driver - in >> some configurations this might trigger an immediate "continue" of an >> ongoing deploy, in others it might simply register the agent as available >> for new deploys in the future. >> > > Maybe another way to look up what node the agent is running on would be by > looking at the MAC address of that node, having it on hand you could then > GET /ports/detail and find which port has that MAC associated with it, > after you find the port you can look at the node_uuid field which holds the > UUID of the node which that port belongs to (All ports have a node_uuid, > it's mandatory). So, right now you would need to list all the ports and > find that MAC address there, but I got a review up that might help you with > it by allowing you to get a port using its address as input: > https://review.openstack.org/#/c/82773/ (GET /ports/detail?address=). > > What you think? > Right, we discussed this possibility as well. Internally that's actually how the first iteration of our lookup call will work (mapping MAC addresses to ports to nodes). This can definitely be made to work, but in my mind it has a few limitations: 1. It limits how we can do lookups. In the future I'd like to be able to consider serial numbers, hardware profiles, etc when trying to map an agent to a node. Needing to expose an API for each of these is going to be infeasible. 2. It limits how we do enrollment. 3. It forces us to expose more of the API to agents. Items 1 and 2 seem like things that someone deploying Ironic is especially likely to want to customize. For example, I might have some business process around replacing NICs where I want to customize how a server is uniquely identified (or even hit an external source to do it), or I might want want to override enrollment to hook into Fuel. While we can probably find a way to solve our current problem, how can we generically solve the need for an agent to talk to a driver (either in order to centralize orchestration, or because access to the database is needed) without needing a Node UUID? Thanks, Russell ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] Nodeless Vendor Passthru API
Hi Russell, Ironic allows drivers to expose a "vendor passthru" API on a Node. This > basically serves two purposes: > > 1. Allows drivers to expose functionality that hasn't yet been > standardized in the Ironic API. For example, the Seamicro driver exposes > "attach_volume", "set_boot_device" and "set_node_vlan_id" passthru methods. > 2. Vendor passthru is also used by the PXE deploy driver as an internal > RPC callback mechanism. The deploy ramdisk makes calls to the passthru API > to signal for a deployment to continue once a server has booted. > > For the purposes of this discussion I want to focus on case #2. Case #1 is > certainly worth a separate discussion - we started this in > #openstack-ironic on Friday. > > In the new agent we are working on, we want to be able to look up what > node the agent is running on, and eventually to be able to register a new > node automatically. We will perform an inventory of the server and submit > that to Ironic, where it can be used to map the agent to an existing Node > or to create a new one. Once the agent knows what node it is on, it will > check in with a passthru API much like that used by the PXE driver - in > some configurations this might trigger an immediate "continue" of an > ongoing deploy, in others it might simply register the agent as available > for new deploys in the future. > Maybe another way to look up what node the agent is running on would be by looking at the MAC address of that node, having it on hand you could then GET /ports/detail and find which port has that MAC associated with it, after you find the port you can look at the node_uuid field which holds the UUID of the node which that port belongs to (All ports have a node_uuid, it's mandatory). So, right now you would need to list all the ports and find that MAC address there, but I got a review up that might help you with it by allowing you to get a port using its address as input: https://review.openstack.org/#/c/82773/ (GET /ports/detail?address=). What you think? > > The point here is that we need a way for the agent driver to expose a > top-level "lookup" API, which doesn't require a Node UUID in the URL. > > I've got a review (https://review.openstack.org/#/c/81919/) up which > explores one possible implementation of this. It basically routes POSTs to > /drivers//vendor_passthru/ to a new method on the > vendor interface. > > Importantly, I don't believe that this is a useful way for vendors to > implement new consumer-facing functionality. If we decide to take this > approach, we should reject drivers try to do so. It is intended *only* for > internal communications with deploy agents. > > Another possibility is that we could create a new API service intended > explicitly to serve use case #2 described above, which doesn't include most > of the existing public paths. In our environment I expect us to allow > agents whitelisted access to only two specific paths (lookup and checkin), > but this might be a better way to achieve that. > > Thoughts? > > Thanks, > Russell > > ___ > 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
[openstack-dev] [Ironic] Nodeless Vendor Passthru API
All, Ironic allows drivers to expose a "vendor passthru" API on a Node. This basically serves two purposes: 1. Allows drivers to expose functionality that hasn't yet been standardized in the Ironic API. For example, the Seamicro driver exposes "attach_volume", "set_boot_device" and "set_node_vlan_id" passthru methods. 2. Vendor passthru is also used by the PXE deploy driver as an internal RPC callback mechanism. The deploy ramdisk makes calls to the passthru API to signal for a deployment to continue once a server has booted. For the purposes of this discussion I want to focus on case #2. Case #1 is certainly worth a separate discussion - we started this in #openstack-ironic on Friday. In the new agent we are working on, we want to be able to look up what node the agent is running on, and eventually to be able to register a new node automatically. We will perform an inventory of the server and submit that to Ironic, where it can be used to map the agent to an existing Node or to create a new one. Once the agent knows what node it is on, it will check in with a passthru API much like that used by the PXE driver - in some configurations this might trigger an immediate "continue" of an ongoing deploy, in others it might simply register the agent as available for new deploys in the future. The point here is that we need a way for the agent driver to expose a top-level "lookup" API, which doesn't require a Node UUID in the URL. I've got a review (https://review.openstack.org/#/c/81919/) up which explores one possible implementation of this. It basically routes POSTs to /drivers//vendor_passthru/ to a new method on the vendor interface. Importantly, I don't believe that this is a useful way for vendors to implement new consumer-facing functionality. If we decide to take this approach, we should reject drivers try to do so. It is intended *only* for internal communications with deploy agents. Another possibility is that we could create a new API service intended explicitly to serve use case #2 described above, which doesn't include most of the existing public paths. In our environment I expect us to allow agents whitelisted access to only two specific paths (lookup and checkin), but this might be a better way to achieve that. Thoughts? Thanks, Russell ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
