Open Stack

Hi

> On 23. Jun 2021, at 12:21, 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).

You touch a very interesting and slippy pot. I belong also to this unlucky category and need to say:
- once forked amount of differences only grows
- differences in the beginning may be coverable by compromises, but most likely at some point you will reach dead end and need to consider alternative solutions
- delivery of the client (here especially talking about OSC) is not that complex as you think
- 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"
- 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 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).


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


Regards,
Artem