Use OpenStack SDK in Nova

Registered by Eric Fried on 2019-04-17

We would like to get rid of Nova's use of python-${service}client for ${service} in glance, ironic, neutron, cinder, etc.

One step toward doing that was integrating keystoneauth1 to set up auth, session, and adapter. While this helped by creating a consistent user experience (all services (except cinder, which never got finished) can be configured using the same options), this was just a façade. Under the covers, we're using that ksa adapter to determine one or two values which we then use to construct the same python-${service}client we've always used. The client would internally construct a whole new ksa adapter using those values.

One approach to cutting out this waste was to find a way to pass the ksa adapter we built on the nova side so it could be used by the client instead of building a new one. We tried this, but found it to be too deeply embedded to be practical. And besides, that still wouldn't get us away from using the python-${service}client.

The next possibility would be to replace calls into python-${service}client with methods that invoke the ${service} APIs directly through the ksa adapter's get/put/etc. primitives. This would entail effectively porting the python-${service}client code into nova. While this would give us the opportunity to clean things up, it would involve a lot of low-level work like version discovery/negotiation, input payload construction and validation, and output processing.

Enter OpenStack SDK, which has a lot of that low-level work done, and presents client APIs via an object model. This exists at varying stages of maturity for different APIs - e.g. nearly full-featured for ironic, but virtually nothing for placement - but at worst provides the same get/put/etc. primitives as ksa Adapter (is in fact a subclass thereof).

This blueprint, expected to be a multi-release effort, proposes to:

- Introduce package requirements and plumbing for the construction of an openstack.connection.Connection object.
- Replace the SchedulerReportClient's ksa Adapter with the SDK's placement proxy. This should be transparent other than a small number of changes to mocks in tests. Eventually, the SDK may implement more support for placement. The framework being in place, we can integrate such changes at our leisure as they become available.
- Replace invocations into python-ironicclient, one at a time, with calls into the SDK's baremetal proxy. Once all ironicclient calls are replaced, remove ironicclient from nova.
- Similar for other services such as glance, neutron, cinder...

Upgrades and Compatibility:
This effort includes work in the SDK [1] to allow construction of the Connection object using the keystoneauth1 conf options we already support. Thus this change *could* be completely transparent to operators. However, we would eventually like to move toward using clouds.yaml rather than oslo.config to set up the Connection's auth/session/adapter properties. This can be put under operator control by supporting a new conf option for each service indicating a service account name. When specified, this option indicates that the service's Connection should be initialized from clouds.yaml using the values under that service account name. If absent, we will expect the full slew of ksa opts as we do today [2].

[2] Note that we currently (stein) still support pre-ksa conf options for setting up python-${service}client, e.g. ironic.api_endpoint. These have been deprecated since queens-ish. We should remove them now, so we don't have a *three*-high stack of alternatives to support.

Blueprint information

Eric Fried
Needs approval
Pending Approval
Series goal:
Milestone target:
Started by
Matt Riedemann on 2019-07-02

Related branches



Gerrit topic:

openstacksdk: Make factory for a CloudRegion from CONF objects:

nova: Introduces the openstacksdk to nova:

nova: Use SDK instead of ironicclient for node.get:

Gerrit topic:

Addressed by:
    WIP/PoC: Use SDK instead of ironicclient for node.get

General question but are any other services doing something like this or would nova be the first? I do see value in dog-fooding on the openstacksdk to at least build up API parity in common tooling. This would be a benefit for *users* of openstack if openstack services developers were also working on the SDK to fulfill their needs and thus the SDK users would have a more feature complete and robust SDK to use (more eyes shallow bugs and all that). There were also performance concerns years ago about the services using the sdk (liberty-era) but it sounds like those concerns no longer exist (were solved somehow). Anyway, I'll personally give a score of "meh and a half" since this seems like extra churn for I'm not sure about a ton of gain (the clouds.yaml thing might be the biggest gain but sounds like it would be a long way off yet). Would definitely be good to get more operator input here since they'd be directly affected by this...too bad this is late for a Train Forum session. -- mriedem 20190425

Addressed by:
    WIP: Use OpenStack SDK for placement

Addressed by:
    WIP/PoC: Use SDK instead of ironicclient for node.list

Addressed by:
    WIP/PoC: Use SDK instead of ironicclient for checking instance exists

Addressed by:
    Introduces the openstacksdk to nova

Gerrit topic:

Addressed by:
    Use SDK instead of ironicclient for setting instance id

Addressed by:
    WIP: Use SDK instead of ironicclient for add/remove instance info from node

Addressed by:
    Spec: Use OpenStack SDK in Nova

Addressed by:
        Use SDK instead of ironicclient for getting network metadata from node

Addressed by:
    Use fields="instance_uuid" when calling Ironic API

[efried 20190910] Marking this complete for Train, since it's an acknowledged multi-release effort and we're done merging stuff this release. We should propose a continuation for this (openstacksdk-in-nova-ussuri) whose spec can be substantially the same but reflect the progress made in Train (framework, placement, and part of ironic) and any course alterations resulting therefrom.

[efried 20190925] Reverting 'implemented' status so we can reuse this bp for the continuation work in ussuri. Spec work should still be as noted above.

Addressed by:
    Spec: Use OpenStack SDK in Nova (Ussuri)

[mriedem 20190926] Re-approved for Ussuri.

[efried 20200131] Pushing this out of ussuri as the owner is no longer going to be working it.


Work Items

This blueprint contains Public information 
Everyone can see this information.