Open Stack

I don't get that logic at all.

Proxying the read commands means that monitoring or report scripts will
work fine. Actual state transition scripts, which can't really work
correctly, as there are too many differences, won't.

	-Sean

On 09/10/2014 12:57 PM, Solly Ross wrote:
> As far as I understand it, though, that's a patch for a read-only mode.  It seems bizzare, and possibly dangerous, to proxy read commands, but not write commands.  It gives the impression that everything's fine until it's not fine (because someone tried to use an existing script to do a create command).  IMHO, it would be better to just tell people up front "Update your scripts to use Ironic, because they won't work at all" instead of leading people (through empirical evidence) to believe that their scripts will work, and then having them discover later that something broke because they tried to create a node.
> 
> Best Regards,
> Solly Ross
> 
> ----- Original Message -----
>> From: "Sean Dague" <sean at dague.net>
>> To: openstack-dev at lists.openstack.org
>> Sent: Wednesday, September 10, 2014 10:33:05 AM
>> Subject: Re: [openstack-dev] On an API proxy from baremetal to ironic
>>
>> 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
>>
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


-- 
Sean Dague
http://dague.net