<div dir="ltr">I thought it might be helpful to show a sample of the output from the proxied commands: Please find the example here: <blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><a href="http://paste.openstack.org/show/Em861wMwFvrFlsWkugfX">http://paste.openstack.org/show/Em861wMwFvrFlsWkugfX</a></div></blockquote><div><br><div><br></div><div>Chris Krelle</div></div><div>NobodyCam</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Sep 10, 2014 at 7:33 AM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 09/09/2014 11:22 PM, Russell Bryant wrote:<br>
> On 09/09/2014 05:24 PM, Michael Still wrote:<br>
>> Hi.<br>
>><br>
>> One of the last things blocking Ironic from graduating is deciding<br>
>> whether or not we need a Nova API proxy for the old baremetal<br>
>> extension to new fangled Ironic API. The TC has asked that we discuss<br>
>> whether we think this functionality is actually necessary.<br>
>><br>
>> It should be noted that we're _not_ talking about migration of<br>
>> deployed instances from baremetal to Ironic. That is already<br>
>> implemented. What we are talking about is if users post-migration<br>
>> should be able to expect their previous baremetal Nova API extension<br>
>> to continue to function, or if they should use the Ironic APIs from<br>
>> that point onwards.<br>
>><br>
>> Nova had previously thought this was required, but it hasn't made it<br>
>> in time for Juno unless we do a FFE, and it has been suggested that<br>
>> perhaps its not needed at all because it is an admin extension.<br>
>><br>
>> To be super specific, we're talking about the "baremetal nodes" admin<br>
>> extension here. This extension has the ability to:<br>
>><br>
>>  - list nodes running baremetal<br>
>>  - show detail of one of those nodes<br>
>>  - create a new baremetal node<br>
>>  - delete a baremetal node<br>
>><br>
>> Only the first two of those would be supported if we implemented a proxy.<br>
>><br>
>> So, discuss.<br>
><br>
> I'm in favor of proceeding with deprecation without requiring the API proxy.<br>
><br>
> In the case of user facing APIs, the administrators in charge of<br>
> upgrading the cloud do not have full control over all of the apps using<br>
> the APIs.  In this particular case, I would expect that the cloud<br>
> administrators have *complete* control over the use of these APIs.<br>
><br>
> Assuming we have one overlap release (Juno) to allow the migration to<br>
> occur and given proper documentation of the migration plan and release<br>
> notes stating the fact that the old APIs are going away, we should be fine.<br>
><br>
> In summary, +1 to moving forward without the API proxy requirement.<br>
<br>
</div></div>The thing is, we have the patch -<br>
<a href="https://review.openstack.org/#/c/120433/" target="_blank">https://review.openstack.org/#/c/120433/</a>, so it's not like there is a<br>
zomg run around to get the patch.<br>
<br>
I think we should FFE this patch as it provides a smoother transition<br>
from baremetal to ironic. The patch is extremely low risk to the rest of<br>
Nova, as it's a surface proxy feature, so lets just land it and move<br>
forward.<br>
<span class="HOEnZb"><font color="#888888"><br>
        -Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" target="_blank">http://dague.net</a><br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>