> -----Original Message----- > From: John Garbutt [mailto:j...@johngarbutt.com] > Sent: Monday, June 1, 2015 7:41 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [nova][api] New micro-version needed for api bug > fix or not? > > On 31 May 2015 at 14:15, Xu, Hejie <hejie...@intel.com> wrote: > > Replied in line with prefix [alex] > > > > -----Original Message----- > > From: John Garbutt [mailto:j...@johngarbutt.com] > > 1) > > We agreed changing a 500 error to an existing error (or making it succeed in > the usual way) is a change that doesn't need a version bump, its a bug fix. > > > > [alex] from the etherpad > https://etherpad.openstack.org/p/YVR-nova-contributor-meetup it said fix 500 > for existed error can be without bump version. If it is new type of error > code, > that would need bump. > > +1 > > > [alex] But I'm not quite understand this one. There maybe some new > functionality add to API, then there are some exception forget to catching, > then > server return 500. After we found this error, I didn't found out the reason we > should bump version. > > Basically, we are saying we need to bump the version when the API user has a > new error code they need to understand. Since 500 is never an "expected" > result, its fine to move those error cases to some other error case the API > user > already understands. > > If there is a new error code required, that means there os something new for > the client to understand, so we need to bump the version, so we tell clients > when that new error code will be available. > > At least thats how I remember the discussion.
I only thought out the new error code only can be introduced by some new functionality or some bug fix for restricting the request checks. In those case, there should already have one version bump for it. The 500 error is generated by that version, we needn't bump version again, just need fix the 500 in the Version we introduced. > > > 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. > > > Now when it comes to your change. It is a bug in the default policy. > > Sadly this policy is also quite hard wired to admin vs non-admin. We still > > need > work to make policy more discoverable, so I don't think we need to make this > any more discoverable as such. > > > > [alex]: This isn't controlled by policy currently, or your think those query > parameter should controlled by policy? > > It is controlled by "context.is_admin". I am thinking all of those should > really > become resource specific policy. Mostly because many larger deployers have > various levels of "admin". > > Thanks, > John > > ________________________________________________________________ > __________ > 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 __________________________________________________________________________ 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
