Open Stack

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.

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.
> > 
> > 
> > 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210623/73972464/attachment.html>