Open Stack

On Fri, Jun 13, 2014 at 11:56 AM, wu jiang <wingwj at gmail.com> wrote:

> If one new feature relates to some API modifications, and its spec has
> already involved the modifications' description, is it necessary to add one
> more API spec here?
>
>

If the new feature is already mentioned in a nova-spec then we don't need
another one. If not, can we just modify an existing nova-spec that has been
approved which should very lightweight process?


>
> On Fri, Jun 13, 2014 at 10:20 AM, wu jiang <wingwj at gmail.com> wrote:
>
>> +1 to Matt.
>>
>>
>> On Fri, Jun 13, 2014 at 10:03 AM, Matt Riedemann <
>> mriedem at linux.vnet.ibm.com> wrote:
>>
>>>
>>>
>>> On 6/12/2014 8:58 PM, Matt Riedemann 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.
>>>>
>>>> [1] https://wiki.openstack.org/wiki/APIChangeGuidelines
>>>> [2] https://review.openstack.org/#/c/99443/
>>>>
>>>>
>>> I think I'd like to say I think something about something a few more
>>> times... :)
>>>
>>>
>>> --
>>>
>>> Thanks,
>>>
>>> Matt Riedemann
>>>
>>>
>>> _______________________________________________
>>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140613/7ffd5f01/attachment-0001.html>