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.
> 
> to level set osc intentionally does not support microverion
> negocaitation, it was a desgin choice not an oversight.
> 
> since many of the plugins have ignored that and implemnted it
> anyway i think it would be good to provide a way to opt into the
> desired behavior. i.e. provide a --latest global flag or change
> the default for the --os-compute-api ectr command to latest in a
> major version fo osc.
[...]

Remind me what you mean specifically by microversion negotiation and
why it's a bad thing? Is detecting the latest supported microversion
and only making calls it will support considered negotiation?

Yesterday in working to try to get recent versions of the SDK to
boot servers in Rackspace, we discovered that 0.99.0 started
supplying network:auto in boot calls which is only supported after a
specific nova microversion, but wasn't checking whether the API was
sufficiently new enough to have that microversion. Is detecting that
condition what you're saying is a bad idea? Or are you saying
specifically doing it in the openstackclient/plugin code is wrong
but it's okay to do it in the SDK?

Sometimes it's unclear to me when people talk about the client
whether they're also referring to the SDK or vice versa, especially
since the client uses the SDK increasingly and both are now
maintained by the same team.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20221123/3ca505bb/attachment-0001.sig>