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 this argument is the fact that we would only be proxying the first two calls, so it wouldn't 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 OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
