On Wed, 2021-06-23 at 10:21 +0000, Wiesel, Fabian 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).
As a compromise, I would suggest to make the client validation configurable as in kubectl with --validate=true.
kubernets has a very differnet approch to api stablity and extensiblity they have versioned extions and support mutlipe versions fo the same extension over tiem. they alsow have a purly plugable api where you can define new contoler to impelent new behavior allowing any depleyment ot have a complete different set of requests and featucre they develop loacl to be integrated into kubernetes which posses problems for interoperatblity between differnt k8s instalations. if we were to add a new gobal option for this we would have to also ensure it default to validating by default. what i think might be a better UX would be for operator to not ship a forked clinet persay but to ship a plugin to the client that also adds your extensions. my other concern with allowing validation to be disabled is that we likely depend on it in part of the code to ensure code is not run unless it passses the validation. it woudl be ineffiecnt to have code to chekc for our precondition to call a function in addtion to the validation so user might get tracebacks or orhter unfriendly errors if they disabled validation. the client validation we have today i belive only enforce enum for example where the value has a fixed set of values. if the field in the api is an unbounded string then the client woudl not perfrom validation of the value of the argument although if we knwo that that argument is only valid if other flags are set then we might check for those. for example if the argument rquires a minium microversion to be used we may not check the value fo the opaqu string filed but woudl validate the microverion range. if you enxtedn the supported feature set in your installation and want to enable the standrd client to work with that you can simply extend the allowed set with a plugin.
Cheers, Fabian