Open Stack

Hi,

On 23/6/21, 13:04, "Artem Goncharov" <artem.goncharov at gmail.com> wrote:
> - we have a project that adds plugins into OSC and in some cases overrides native behaviour of it. Delivery is as easy as “pip install openstackclient MY_FOKED_CLOUD_PLUGINS_PROJECT”. It is not that different from initially doing “pip install openstackclient" - we have a project that adds plugins into OSC and in some cases overrides native behaviour of it. Delivery is as easy as “pip install openstackclient MY_FOKED_CLOUD_PLUGINS_PROJECT”. It is not that different from initially doing “pip install openstackclient"

How do you manage then the rest of the life-cycle of the client software? And other languages?

>    - fraction of seconds there, fraction in another place and suddenly users are crying: why the heck this tool is so slow (here I mean another side of the coin where simply forcing users to retry invocation with corrected set of parameters with +4s for initialisations, +1s on laggy network, + some more retries with further problems, + cleaning up after really failed attempts, etc are making users mad)

I agree that responsiveness is good, but I think, the proposed client validation won't make much of a dent there.

>    - I am personally 100% belonging to "fail early” group. It just take much more efforts explaining to the user what this bloody server response without any message in it means (we all know the sad reality of usefulness of some of the responses).

I think that points to more problems with the client-side approach, and is for me another argument to do it server-side:
Doing the validation in the OSC means that other clients (java, go, etc...) are not benefitting from the work.
Server-side, I can roll out an improved error message as fast as my deployment pipeline allows to all users and all clients.
Which adds another point: The more logic you have in the client, the more likely they are going deviate from the server. Another source of bugs.
And what about the error messages themselves? How do we ensure that they are consistent across the whole user-base?
If they are client side, they differ from version to version, and language to language.

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

>  Sounds really like a reasonable compromise (but I would reverse the flag to allow skipping - I hate possibility to create broken resources), but as I mentioned earlier - sooner or later you will start paying for the fork. So start doing things proper from the beginning.

I agree, if going for client-side validation, would go with the validation being on by default.

Cheers,
  Fabian