[openstack-dev] On an API proxy from baremetal to ironic

Russell Bryant rbryant at redhat.com
Wed Sep 10 03:22:41 UTC 2014


On 09/09/2014 05:24 PM, Michael Still wrote:
> Hi.
> 
> One of the last things blocking Ironic from graduating is deciding
> whether or not we need a Nova API proxy for the old baremetal
> extension to new fangled Ironic API. The TC has asked that we discuss
> whether we think this functionality is actually necessary.
> 
> It should be noted that we're _not_ talking about migration of
> deployed instances from baremetal to Ironic. That is already
> implemented. What we are talking about is if users post-migration
> should be able to expect their previous baremetal Nova API extension
> to continue to function, or if they should use the Ironic APIs from
> that point onwards.
> 
> Nova had previously thought this was required, but it hasn't made it
> in time for Juno unless we do a FFE, and it has been suggested that
> perhaps its not needed at all because it is an admin extension.
> 
> To be super specific, we're talking about the "baremetal nodes" admin
> extension here. This extension has the ability to:
> 
>  - list nodes running baremetal
>  - show detail of one of those nodes
>  - create a new baremetal node
>  - delete a baremetal node
> 
> Only the first two of those would be supported if we implemented a proxy.
> 
> So, discuss.

I'm in favor of proceeding with deprecation without requiring the API proxy.

In the case of user facing APIs, the administrators in charge of
upgrading the cloud do not have full control over all of the apps using
the APIs.  In this particular case, I would expect that the cloud
administrators have *complete* control over the use of these APIs.

Assuming we have one overlap release (Juno) to allow the migration to
occur and given proper documentation of the migration plan and release
notes stating the fact that the old APIs are going away, we should be fine.

In summary, +1 to moving forward without the API proxy requirement.

-- 
Russell Bryant



More information about the OpenStack-dev mailing list