Open Stack

Thanks a lot for the reply.

I have already registered a BP for this, and will submit a spec for N, we
can discuss the details in the spec then.



On Sun, Mar 6, 2016 at 2:01 AM, Matt Riedemann <mriedem at linux.vnet.ibm.com>
wrote:

>
>
> On 3/5/2016 9:48 AM, Adam Young wrote:
>
>> On 03/05/2016 12:27 AM, Chris Friesen wrote:
>>
>>> On 03/04/2016 03:42 PM, Matt Riedemann wrote:
>>>
>>>>
>>>>
>>>> On 3/3/2016 9:14 PM, Zhenyu Zheng wrote:
>>>>
>>>>> Hm, I found out the reason:
>>>>>
>>>>> https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/servers.py#L1139-L1145
>>>>>
>>>>>
>>>>> here we filtered out parameters like "deleted", and that's why the API
>>>>> behavior is like above mentioned.
>>>>>
>>>>> So should we simple add "deleted" to the tuple or a microversion is
>>>>> needed?
>>>>>
>>>>
>>> Nice find. This is basically the same as the ip6 case which required
>>>> microversion 2.5 [1]. So I think this is going to require a
>>>> microversion in
>>>> Newton to fix it (which means a blueprint and a spec since it's an
>>>> API change).
>>>> But it's pretty trivial, the paperwork is the majority of the work.
>>>>
>>>> [1] https://review.openstack.org/#/c/179569/
>>>>
>>>
>>> Does it really need a spec given that microversions are documented in
>>> the codebase?
>>>
>>> That almost seems like paperwork for the sake of following the rules
>>> rather than to serve any useful purpose.
>>>
>>> Is anyone really going to argue about the details?
>>>
>>>
>> I've been lurking on this discussion. I was worried that you were going
>> to try to hard code "admin" somewhere in here.
>>
>> If the only change is that the currently accepted set of params is
>> enforced with the current set of policy rules, just in a slightly
>> different place, it will not break people, and thus I would think no
>> microversion is essential.  However, if the the user might need to test
>> which way policy is enforced in order to use the right code path when
>> doing a client call, then a microversion would be needed.
>>
>>
>>
>> Chris
>>>
>>>
>>>
>>> __________________________________________________________________________
>>>
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> The ip6 case and microversion 2.5 is exactly the same scenario and sets
> precedent here, so yes we need a microversion which makes it an API change
> which according to our policy requires a spec. I realize it's trivial, but
> them's the rules.
>
> As far as I can tell, this is latent behavior since forever and no one has
> freaked out about it before, so I don't think doing things by the book and
> doing that in Newton is going to cause any problems.
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> 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/20160307/2e6b4080/attachment.html>