Open Stack

> 
> On 2022-11-23 14:44:01 +0000 (+0000), Sean Mooney wrote:
> [...]
>> i hate that i bring this up but one of the design guidlines of OSC
>> was commands must not auto negociagte the latest micorverion. that
>> again was for consitency so that command would work the same
>> across different clouds with different api versions. many plugins
>> have broken this design requirement btu the core osc client still
>> maintains its orginal design.
>> 

My problem with that (and the reason we started moving away) was forcing user to explicitly know which micro version added some feature, which broke it again and which repaired it finally and questioning which version is actually available on a certain cloud. This is/was causing quite a mess for regular users (not advanced users). I would even state it like that: why should a regular user ever care in which microversion it became possible to get tags fetched together with servers or how to figure out which micro version you need to set once you depend on features from different micro versions. This is not user friendly at all.

Chances a single person is using OSC to communicate to different clouds (and as such get inconsistent results) are much lower then needing to remember (and hardcode) micro versions for you talking to a single cloud. On the other side - there is nothing blocking you to specify —os-X-api-version to get the expected result.

From the consistency pov I would say it is better to have same behaviour in SDK/OSC/Ansible rather than CLI explicitly doing an opposite to Ansible. And again - for me it is very important to make tools user friendly while having full flexibility and consistency.

Last but no least, I personally never knew of such design requirement in OSC.

Artem