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

Sean Mooney smooney at redhat.com
Wed Jun 23 00:31:00 UTC 2021


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.
i agree with keeping the validation in the clinet by the way.
more details on the usecase tehy had below.
> 
> 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)?
no that is not possible, any extenions of the policies woudl requrie a
new micro version. we have previously added new microversion when we
added the soft affintiy policy.  as with any new microversion we woudl
naturally also extend the clinet to support that new microverison.

nova has not supported api extnension for a very long time and i dont
forsee us making this plugable or reintoducing api extentions in the
sort to near term.

i receved more infomation fomr out downstream support engienrs on what
the customer is actlly trying to do. our supprot engeienr discorverd
this old spec form jay to add aggrate affintiy policies.
https://review.opendev.org/c/openstack/nova-specs/+/529135/6/specs/rocky/approved/aggregate-affinity.rst

the costomer usecase is rack level affinity/antiafinity to ensure that
vms are schduled to differnt top of rack switchs. they model thos tor
failure domains as host aggreates and implented a custome filter to
implemant that affintiy and anit affinity. they also however modifid
the server side vlaidation brackin micorverion compatiablty by
intoducing new tor-affintiy policies.

skiming the spec it is mainly focused on ironic but im really not sure
why we have nto added an agrrate level affinity/antiaffinty policy
already. it has application for non ironic host too and woudl provide a
way to do geneirc fault domain modeling. granted it woudl eb nice to
model this in palcment somehow but supporting it at all would be
valueable.

we have added affinity rules for  anti-affinity in the form of
max_server_per_host
https://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/complex-anti-affinity-policies.html

to me sepcifying a failrue domain in the form of an affinity_scope
e.g. affinity_scope=host or affintiy_scope=aggreate or
max_servers_per_aggreate could be another alternivie to a new policy 
but the over all the usecase seams valid regardless of how we adress
it.

doing this as an nova fork/api exteion however is not really a valid
reason to remove validation form teh client. the could also patch the
client with an osc plugin or create a fork of it also presumable.
they woud just have to monkey patch the existing server group command
or reimplement it and override the in tree one.

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





More information about the openstack-discuss mailing list