Open Stack

 ---- 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
 > 
 >