
<html><head></head><body><div>On Tue, 2021-06-22 at 23:49 +0300, Andrey Kurilin wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><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></blockquote><div><br></div><div>Cool, that's my thinking also.</div><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div dir="ltr"><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.</div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>Stephen</div><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div><br></div><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 type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>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></div><div><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></div><div><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></div><div><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></div><div><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></div><div><br></div><div><br></div><div><br></div></blockquote></div><div><br clear="all"><br></div></blockquote><div><br></div><div><span></span></div></body></html>