Open Stack

Hey everyone,

Maybe I can add some context here.

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.

   - Computes are dual-homed to two different TOR (top-of-rack) switches.
   - Two TORs (a tor pair) will connect up to X amount of computes.
   - A user deploys 10 Virtual Machines with anti-affinity enabled.
   - 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.
   - The TOR pair becomes a SPOF for the entire deployment.

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.

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.

Let me know if you have any questions!

Thanks!

On Thu, Jun 24, 2021 at 12:01 PM Ghanshyam Mann <gmann at ghanshyammann.com>
wrote:

>  ---- On Thu, 24 Jun 2021 07:22:09 -0500 Wiesel, Fabian <
> fabian.wiesel at sap.com> wrote ----
>  >
>  >
>  > On 23/6/21, 18:03, "Ghanshyam Mann" <gmann at ghanshyammann.com> wrote:
>  >
>  >      ---- On Wed, 23 Jun 2021 05:21:58 -0500 Wiesel, Fabian <
> fabian.wiesel at sap.com> wrote ----
>  >      > I take a different view, possibly because I am in a similar
> position as the requestor.
>  >      > I also work on a openstack installation, which we need to patch
> to our needs.
>  >      > We try to do everything upstream first, but chances are, there
> will be changes which are not upstreamable.
>  >      >
>  >      > 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.
>  >      > 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.
>  >      > 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).
>  >
>  >     What are the exact reason for not upstreaming the changes? We have
> microversion mechanish in Nova API to improve/change the API in
>  >     backward compatible and discoverable way. That will be helpful to
> add the more API/changing existing APIs without impacting the existing
>  >     user of that API.
>  >
>  > 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.
>  > Any API change we plan to do, we try to get consensus with upstream
> first.
>  >
>  > 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.
>
> Thanks Fabian for explaining in detail. I understand the situation.
>
> In Nova, if you have API change request, we do follow the design
> discussion in specs repo first and then implementation should not take
> 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
> it available at customer side depends on how soon you upgrade to that
> release.
>
> But I feel this is a general issue on long release cycle not just API or
> Client.
>
> 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
> in API side is not good but at least the client can be flexible. May be
> osc team can provide their opinion?
>
>
> -gmann
>
>  >
>  > 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.
>  >
>  > Cheers,
>  >   Fabian
>  >
>  >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210629/decca36e/attachment-0001.html>