Open Stack

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/<driver_name>/vendor_passthru/<method_name> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140324/e59cfbf2/attachment.html>