Open Stack

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