On Fri, Jun 13, 2014 at 11:56 AM, wu jiang <win...@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 <win...@gmail.com> wrote: > >> +1 to Matt. >> >> >> On Fri, Jun 13, 2014 at 10:03 AM, Matt Riedemann < >> mrie...@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 <mi...@stillhq.com >>>>> <mailto:mi...@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@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@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
