[nova][osc][api-sig] How strict should our clients be?

Ghanshyam Mann gmann at ghanshyammann.com
Wed Jun 23 16:03:07 UTC 2021


 ---- On Wed, 23 Jun 2021 04:16:21 -0500 Stephen Finucane <stephenfin at redhat.com> wrote ----
 > On Tue, 2021-06-22 at 23:49 +0300, Andrey Kurilin wrote:Hi folks!
 > As a guy who was top 1 contributor to novaclient at some point, I tried to extend a validation at the client-side as much as possible.I mean, I really like the approach when the user sees a validation error in an ms (or a second depending on the system and plugins) without passing the auth and sending any request to API, so big +1 to leave enum of possible choices there.
 > 
 > Cool, that's my thinking also.
 > BUT I have one concern here: does it possible that the number of official policies will be extended or it becomes pluggable(without patching of nova code itself)? In this case, it would be nice to be a bit less strict.
 > As Sean has said elsewhere, there's no way to extend this without a microversion. I think it's fair to request that users upgrade their client if they wish to support newer microversions.

Yes, plugin-able or extension mechanisms had many other problems in term of interoperability or so. I think microversion is good way to introduce the new API changes without breaking existing users.

 > Stephen
 > 
 > вт, 22 июн. 2021 г. в 20:51, Sean Mooney <smooney at redhat.com>:
 > On Tue, 2021-06-22 at 17:17 +0000, Jeremy Stanley wrote:
 > > On 2021-06-22 17:39:42 +0100 (+0100), Stephen Finucane wrote:
 > > [...]
 > > > Apparently someone has been relying on a bug in Nova to pass a
 > > > different value to the API that what the schema should have
 > > > allowed, and they are dismayed that the client no longer allows
 > > > them to do this.
 > > [...]
 > > 
 > > I can't find where they explained what new policy they've
 > > implemented in their fork. Perhaps if they elaborated on the use
 > > case, it could be it's something the Nova maintainers would accept a
 > > patch to officially extend the API to incorporate, allowing that
 > > deployment to un-fork?
 > my understandign is that they are trying to model fault domains an have
 > a fault domain aware anti affintiy policy that use host-aggreate or azs
 > to model the fault to doamin.
 > 
 > they reasched out to us downstream too about this and all i know so
 > fart is they are implemetneign there own filter to do this which is
 > valid. what is not valid ti extending a seperate api in this case the
 > server group api to then use as an input to the out of tree filter.
 > 
 > if they had use a schduler hint which inteionally support out of tree
 > hints or a flaovr extra spec then it would be fine. the use fo a custom
 > server group policy whne the server groups is not a defiend public
 > extion point is the soucce of the confilct.
 > 
 > the use case of an host aggrate anti affinti plicy while likely not
 > efficent to implement is at leaset a somewhat resonable one that i
 > could see supporting upstream. although there are many edgcases with
 > regard to host being in mutliple host aggreates. if they are doing this
 > based on avaiablity zone that is simler since a hsot can only be in one
 > az.
 > 
 > in anycase it woudl be nice if they brought there usecase upstream or
 > even downstream so we could find a more supprotable way to enable it.
 > 
 > 
 > 
 > 
 > 
 > 
 > 



More information about the openstack-discuss mailing list