Open Stack

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.

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.

вт, 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.
>
>
>
>

-- 
Best regards,
Andrey Kurilin.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210622/7ff4fa57/attachment.html>