Open Stack

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.

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