Open Stack

On Wed, 2022-11-23 at 14:55 +0000, Jeremy Stanley wrote:
> 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?
detecting and refusing to send if i request 2.100 and it only support 2.50
woudl be not really negociation sending the req	ust automaticaly with 2.50 is negociation

if we did not want to break the orginal design but improve the ux my markign each command
with the minium rpc that was requried and only request that. that would provide a stabel behavior
provided the cloud supported that mini 

> 
> 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?
the sdk is not auto negociating if its using a hard coded value.
renwer micoversions are generally not backwards compatiable.
they may be additive but the can be subtractive changes so in general you
need to look a the parmater passed to the sdk fucntion to knwo what range of micorverisons
are valid and then choose a approtiate one.

just using lateset in the sdk without backleveling to the max supported in the cloud at a minium
is a bad idea since the sdk is ment to support older openstack relesase. its also a bad idea in general
as the sdk is ment to provide stable behvior for applicaitons and newer micoverion can remove fucntionality
that is still aviabel if you use the older microverions.

so client and the sdk shoudl default to the oldest microveion that is supproted
for a given request not the newest to provide stable behvior.

as an example before 2.92 nova support keypair generation for rsa ssh keys
https://docs.openstack.org/nova/latest/reference/api-microversion-history.html#microversion-2-92
with 2.92+  or latest (2.93) that functionality is not aviable however the same request using the
old microverion will work since the code still exist in nova.

defaulting to auto for this api will break user of a zed cloud.
defaultin to the oldest version that supported this api 2.1 will still work with zed.

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

the sdk really shoudl not default to latest.
the unifed client does nto today to provide a stable cli but could
if we dont want the openstack client to provide a stable scripting interface.

the comment i have heard alot is if you want to script agaisnt the nova api use the python client or sdk
but that is not useful if you are writng said script in bash or another language.
for example in devstack we use osc directly when need and i dont think we are ever going to rewite that
to use python so i dont like saying a stable commandline interface is out of scope of the unified openstack clinet.