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

Chris K nobodycam at gmail.com
Wed Sep 10 16:35:57 UTC 2014


I thought it might be helpful to show a sample of the output from the
proxied commands: Please find the example here:

http://paste.openstack.org/show/Em861wMwFvrFlsWkugfX



Chris Krelle
NobodyCam


On Wed, Sep 10, 2014 at 7:33 AM, Sean Dague <sean at dague.net> wrote:

> On 09/09/2014 11:22 PM, Russell Bryant wrote:
> > 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.
>
> The thing is, we have the patch -
> https://review.openstack.org/#/c/120433/, so it's not like there is a
> zomg run around to get the patch.
>
> I think we should FFE this patch as it provides a smoother transition
> from baremetal to ironic. The patch is extremely low risk to the rest of
> Nova, as it's a surface proxy feature, so lets just land it and move
> forward.
>
>         -Sean
>
> --
> Sean Dague
> http://dague.net
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140910/e80dd659/attachment.html>


More information about the OpenStack-dev mailing list