Open Stack

On Fri, Jun 13, 2014 at 11:28 AM, Matt Riedemann <mriedem at linux.vnet.ibm.com
> wrote:

>
>
> On 6/12/2014 5:58 PM, Christopher Yeoh wrote:
>
>> On Fri, Jun 13, 2014 at 8:06 AM, Michael Still <mikal at stillhq.com
>> <mailto:mikal at stillhq.com>> wrote:
>>
>>     In light of the recent excitement around quota classes and the
>>     floating ip pollster, I think we should have a conversation about the
>>     review guidelines we'd like to see for API changes proposed against
>>     nova. My initial proposal is:
>>
>>       - API changes should have an associated spec
>>
>>
>> +1
>>
>>       - API changes should not be merged until there is a tempest change
>> to
>>     test them queued for review in the tempest repo
>>
>>
>> +1
>>
>> Chris
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> We do have some API change guidelines here [1].  I don't want to go
> overboard on every change and require a spec if it's not necessary, i.e. if
> it falls into the 'generally ok' list in that wiki.  But if it's something
> that's not documented as a supported API (so it's completely new) and is
> pervasive (going into novaclient so it can be used in some other service),
> then I think that warrants some spec consideration so we don't miss
> something.
>
> To compare, this [2] is an example of something that is updating an
> existing API but I don't think warrants a blueprint since I think it falls
> into the 'generally ok' section of the API change guidelines.
>
>
So really I see this a new feature, not a bug fix. Someone thought that
detail was supported when writing the documentation but it never was. The
documentation is NOT the canonical source for the behaviour of the API,
currently the code should be seen as the reference. We've run into issues
before where people have tried to align code to the fit the documentation
and made backwards incompatible changes (although this is not one).

Perhaps we need a streamlined queue for very simple API changes, but I do
think API changes should get more than the usual review because we have to
live with them for so long (short of an emergency revert if we catch it in
time).

[1] https://wiki.openstack.org/wiki/APIChangeGuidelines
> [2] https://review.openstack.org/#/c/99443/
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20140613/069d87bc/attachment.html>