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