Open Stack

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.