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