2015-06-01 13:40 GMT+02:00 John Garbutt <j...@johngarbutt.com>: > On 31 May 2015 at 14:15, Xu, Hejie <hejie...@intel.com> wrote: >> Replied in line with prefix [alex] >> >> -----Original Message----- ... >> 2) >> We also agreed that all micro version bumps need a spec, to help avoid is >> adding more "bad" things to the API as we try and move forward. >> This is heavy weight. In time, we might find certain "good" patterns where >> we want to relax that restriction, but we haven't done enough changes to >> agree on those patterns yet. This will mean we are moving a bit slower at >> first, but it feels like the right trade off against releasing (i.e. >> something that lands in any commit on master) an API with a massive bug we >> have to support for a long time. >> >> [alex]: For this case, do we need register a blueprint for it? Maybe we just >> reference the bug in the nova-spec is enough. > > Right now, we have said everything needs a spec. They can be a very, > very, short spec. > > It might become clear there are some places we should skip this, as > clear patterns emerge. > But as we consider every commit a "release", this is very dangerous, > hence the caution we are applying here.
So I have now submitted a spec proposal at https://review.openstack.org/187835 and added the microversion to https://review.openstack.org/179569. I'm wondering though whether the current API behaviour here should be changed more generally. Is there a plausible reason to silently discard options that are not allowed for non-admins? For me it would make more sense to return an error in that case. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
