<div dir="ltr">Hey everyone,<div><br></div><div>Maybe I can add some context here.</div><div><br></div><div>The initial question comes from an initiative to create a custom constraint/affinity solution to address a scheduling issue we've seen from time to time.</div><div><ul><li>Computes are dual-homed to two different TOR (top-of-rack) switches.</li><li>Two TORs (a tor pair) will connect up to X amount of computes.</li><li>A user deploys 10 Virtual Machines with anti-affinity enabled.</li><li>Due to the default scheduler filters (RAM, CPU) and stacking/spreading allocations, Openstack places all 10 VMs on the same TOR pair but on different computes to respect the anti-affinity constraint.</li><li>The TOR pair becomes a SPOF for the entire deployment.</li></ul><div>This was addressed by creating a new anti-affinity filter, overriding part of the default Nova code. A "tor-anti-affinity" filter can now be attached to a server-group.</div></div><div><br></div><div>There might be better ways to implement that kind of filtering based on infrastructure external to Openstack (AZ, host-aggregates, bettter spreading of instances to prevent compute stacking) but it's the way it was initially implemented.</div><div><br></div><div>Let me know if you have any questions!</div><div><br></div><div>Thanks!</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 24, 2021 at 12:01 PM Ghanshyam Mann <<a href="mailto:gmann@ghanshyammann.com">gmann@ghanshyammann.com</a>> wrote:<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 Thu, 24 Jun 2021 07:22:09 -0500 Wiesel, Fabian <<a href="mailto:fabian.wiesel@sap.com" target="_blank">fabian.wiesel@sap.com</a>> wrote ----<br>
 > <br>
 > <br>
 > On 23/6/21, 18:03, "Ghanshyam Mann" <<a href="mailto:gmann@ghanshyammann.com" target="_blank">gmann@ghanshyammann.com</a>> wrote:<br>
 > <br>
 >      ---- On Wed, 23 Jun 2021 05:21:58 -0500 Wiesel, Fabian <<a href="mailto:fabian.wiesel@sap.com" target="_blank">fabian.wiesel@sap.com</a>> wrote ----<br>
 >      > I take a different view, possibly because I am in a similar position as the requestor.<br>
 >      > I also work on a openstack installation, which we need to patch to our needs.<br>
 >      > We try to do everything upstream first, but chances are, there will be changes which are not upstreamable.<br>
 >      > <br>
 >      > We also have large user-base, and it is a great advantage to be able to point people to the official client, even if the server is not the official one.<br>
 >      > A strict client policy would require us to fork the client as well, and distribute that to our user-base. With a couple of thousand users, that is not so trivial.<br>
 >      > In my point-of-view, such a decision would tightly couple the client to the server for a limited benefit (a fraction of seconds earlier error message).<br>
 > <br>
 >     What are the exact reason for not upstreaming the changes? We have microversion mechanish in Nova API to improve/change the API in<br>
 >     backward compatible and discoverable way. That will be helpful to add the more API/changing existing APIs without impacting the existing<br>
 >     user of that API.<br>
 > <br>
 > Currently, we do not have any API changes and our team inside SAP is pushing back against custom changes in the API from our user-base. <br>
 > Any API change we plan to do, we try to get consensus with upstream first.<br>
 > <br>
 > But chances are, that there are requests within our company we must fulfill (even if our team itself may disagree) within a certain timeline, and I do not expect that the community will comply with either the timeline or the request itself.<br>
<br>
Thanks Fabian for explaining in detail. I understand the situation. <br>
<br>
In Nova, if you have API change request, we do follow the design discussion in specs repo first and then implementation should not take<br>
much time (depends on author activeness on updating review comment or so). All this is possible to merger in one cycle itself but to make<br>
it available at customer side depends on how soon you upgrade to that release.<br>
<br>
But I feel this is a general issue on long release cycle not just API or Client.<br>
<br>
In that case, how about providing a config option to disable the client side strict validation (by default we can keep the validation) ? Doing that<br>
in API side is not good but at least the client can be flexible. May be osc team can provide their opinion?<br>
<br>
<br>
-gmann<br>
<br>
 > <br>
 > The changes we do not try to upstream are simply things we consider workarounds for our special situation: We are reaching the supported limits of our vendor (VMware), and we are trying to get our vendor to fix those.<br>
 > <br>
 > Cheers,<br>
 >   Fabian<br>
 > <br>
 > <br>
<br>
</blockquote></div>