Open Stack

 ---- On Wed, 23 Jun 2021 05:21:58 -0500 Wiesel, Fabian <fabian.wiesel at sap.com> wrote ----
 > Hi,
 > 
 > 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.

-gmann

 > 
 > As a compromise, I would suggest to make the client validation configurable as in kubectl with --validate=true.
 > 
 > Cheers,
 >   Fabian
 > 
 > 
 >