(Nova) Microversion handling

[voelzmo]

This is a follow-up for the discussions triggered in https://github.com/fog/fog-openstack/pull/340#pullrequestreview-80372167

Although the discussion started around compute/nova, this might be relevant for all other OpenStack projects which support microversions.

Specifically, we should discuss the following questions

• Which microversions should fog-openstack aim to support and what is the policy to update it?
• Should there be a minimum supported microversion?
• How to test compatibility with microversions? Is there an integration build running against the latest release of OpenStack?
• What about introduction of specific new features that require the microversion bump? How can feature authors check that nothing else breaks when updating the microversion?
• ???

[gildub]

@voelzmo, thanks for opening the "official" thread ;)

Before trying to answer questions, I would like to provide some information to feed the context.

BTW, I wish Nova developers (among others Openstack devs) to join this discussion.

The challenge for OpenStack API consumers to handle microversions has been raised, at latest during API WG meetings at OpenStack PTG in Denver and also at OpenStack summit down under in Sydney.

What clearly came out are:

• The fact that no SKDs, no matter the language has people working full time on maintaining them, with the exception of Openstack Client (Python CLI).
• Although there is a clear practice about how new features are added through microversions, the Openstack community doesn't provide a clear way of how to handle their lifecycle.

Effectively, having to track down every change for every API is not sustainable, unless there is a way to automate such process and be able to tell when an API has changed and what has changed.This is where APIs schema can help, having API definitions such as resources, parameters, types defined in a tree format. APIs schema allow more automation to take place and differences can also be automatically detected. For more information please check API Schema generation and API Guidelines for APIs Schema as part of API WG. This is very important because the users are the ones pushing for changes and the OpenStack community must hear them. So please add your weight in.

As a practical example, Ruby gem Misty is using APIs Reference until APIs Schema are available. The requests are retrieved automatically. Microversions are supported and any microversion can be submitted by the user. Meanwhile microversion changes won't be fully handled until there is better lifecycle in place along API Schema.

Misty is an Openstack API conduit, which job is to send/receive requests, like Excon but dedicated to OpenStack plus the dynamic management of the API resources.

I believe we need to have more modularity and offer the @connection layer as a plug-in, leaving the choice between Excon, Misty or something else,

So with that in mind, I partly answer those questions:

Which microversions should fog-openstack aim to support

Ideally always the latest. An API schema approach can make that happen.

what is the policy to update it?

With API Schema approach

Should there be a minimum supported microversion?

With API Schema approach the latest version supported is always the one from latest API schema supported.

How to test compatibility with microversions? Is there an integration build running against the latest release of OpenStack?

OpenLab project came online earlier this year and is looking for a Ruby SDK to offer integration tests.

What about introduction of specific new features that require the microversion bump?

With API Schema this comes automatically.

How can feature authors check that nothing else breaks when updating the microversion?

Integration tests to validate