With my admittedly limited knowledge of the whole Ironic process, the question 
seems to me to be: "If we don't implement a proxy, which people are going to 
have a serious problem?"

Do we have an data on which users/operators are making use of the baremetal API 
in any extensive fashion?  If nobody's using it, or the people using it aren't 
using in an
extensive fashion, I think we don't need to make a proxy for it.  Strengthening 
argument is the fact that we would only be proxying the first two calls, so it 
be a drop-in replacement anyway.

Best Regards,
Solly Ross

----- Original Message -----
> From: "Michael Still" <mi...@stillhq.com>
> To: "OpenStack Development Mailing List" <openstack-dev@lists.openstack.org>
> Sent: Tuesday, September 9, 2014 5:24:11 PM
> Subject: [openstack-dev] On an API proxy from baremetal to ironic
> 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.
> Thanks,
> Michael
> --
> Rackspace Australia
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

OpenStack-dev mailing list

Reply via email to