[Virtual PTG][nova][sdk] Future of microversion support in SDK
tl;dr Artom to work on catching up the SDK to Nova's latest microversion, any new Nova microversion should come with a corresponding SDK patch. Hello folks, In the SDK/CLI room today we discussed making openstackclient (osc form now on) the main client for interacting with an OpenStack cloud and eventually getting rid of the python-*clients. For context, openstacksdk (sdk from now on) currently has microversion support similar to how python-*clients handle it: autonegotiate with the server to the greatest common microversion. Osc, on the other hand, defaults to 2.1 - anything higher than that needs to be specified on the command line. The long term plan is to move osc to consume sdk. In light of all this, we decided that the best way to achieve the goal stated in the first paragraph is to: 1. Catch up sdk to Nova. This isn't as daunting as it looks, as the latest microversion sdk currently supports is 2.72. This means there's "only" two cycles of catchup to do before we reach Nova's current max of 2.87. I (Artom) have signed on to do that work, and Mordred has kindly promised quick review. 2. Officialise a Nova policy of "any new microverison should come with a corresponding SDK patch." This is essentially what [1] is aiming for, and it already has wide buy-in from the Nova community. Converting osc to consume sdk is left to the osc/sdk community, though obviously any help there will be appreciated, I'm sure. Please keep me honest if I said anything wrong :) Cheers! [1] https://review.opendev.org/#/c/717722/
On Mon, Jun 1, 2020 at 13:11, Artom Lifshitz <alifshit@redhat.com> wrote:
tl;dr Artom to work on catching up the SDK to Nova's latest microversion, any new Nova microversion should come with a corresponding SDK patch.
Hello folks,
In the SDK/CLI room today we discussed making openstackclient (osc form now on) the main client for interacting with an OpenStack cloud and eventually getting rid of the python-*clients.
For context, openstacksdk (sdk from now on) currently has microversion support similar to how python-*clients handle it: autonegotiate with the server to the greatest common microversion. Osc, on the other hand, defaults to 2.1 - anything higher than that needs to be specified on the command line. The long term plan is to move osc to consume sdk.
In light of all this, we decided that the best way to achieve the goal stated in the first paragraph is to:
1. Catch up sdk to Nova. This isn't as daunting as it looks, as the latest microversion sdk currently supports is 2.72. This means there's "only" two cycles of catchup to do before we reach Nova's current max of 2.87. I (Artom) have signed on to do that work, and Mordred has kindly promised quick review.
There is more work than that as support for some of the older microversions are also missing. See the etherpad [2]
2. Officialise a Nova policy of "any new microverison should come with a corresponding SDK patch." This is essentially what [1] is aiming for, and it already has wide buy-in from the Nova community.
Converting osc to consume sdk is left to the osc/sdk community, though obviously any help there will be appreciated, I'm sure.
Please keep me honest if I said anything wrong :)
Cheers!
[2] https://etherpad.opendev.org/p/compute-api-microversion-gap-in-osc
On Tue, Jun 2, 2020 at 5:43 AM Balázs Gibizer <balazs.gibizer@est.tech> wrote:
On Mon, Jun 1, 2020 at 13:11, Artom Lifshitz <alifshit@redhat.com> wrote:
tl;dr Artom to work on catching up the SDK to Nova's latest microversion, any new Nova microversion should come with a corresponding SDK patch.
Hello folks,
In the SDK/CLI room today we discussed making openstackclient (osc form now on) the main client for interacting with an OpenStack cloud and eventually getting rid of the python-*clients.
For context, openstacksdk (sdk from now on) currently has microversion support similar to how python-*clients handle it: autonegotiate with the server to the greatest common microversion. Osc, on the other hand, defaults to 2.1 - anything higher than that needs to be specified on the command line. The long term plan is to move osc to consume sdk.
In light of all this, we decided that the best way to achieve the goal stated in the first paragraph is to:
1. Catch up sdk to Nova. This isn't as daunting as it looks, as the latest microversion sdk currently supports is 2.72. This means there's "only" two cycles of catchup to do before we reach Nova's current max of 2.87. I (Artom) have signed on to do that work, and Mordred has kindly promised quick review.
There is more work than that as support for some of the older microversions are also missing. See the etherpad [2]
Yep, I'm aware of that. I had to double-check with the other Artem (gtema) on IRC because you made me doubt myself, but those are gaps in *osc*, not *sdk*. SDK is actually pretty well caught up. And since it's the future, I've specifically made a point of concentrating on SDK, and leaving the work to convert osc to using sdk to Monty and Artem and friends :)
2. Officialise a Nova policy of "any new microverison should come with a corresponding SDK patch." This is essentially what [1] is aiming for, and it already has wide buy-in from the Nova community.
Converting osc to consume sdk is left to the osc/sdk community, though obviously any help there will be appreciated, I'm sure.
Please keep me honest if I said anything wrong :)
Cheers!
[2] https://etherpad.opendev.org/p/compute-api-microversion-gap-in-osc
participants (2)
-
Artom Lifshitz
-
Balázs Gibizer