Spec: Use OpenStack SDK in Nova
This is a proposal to get rid of Nova's use of python-${service}client
for $service in glance, ironic, neutron, cinder, etc and replace them
with the OpenStack SDK.
Change-Id: I9aadc5e653e9f5af0d47028ffe74eaf439658950
Implements: blueprint openstacksdk-in-nova
This commit is contained in:
Dustin Cowles
278
specs/train/approved/openstacksdk-in-nova.rst
Normal file
278
specs/train/approved/openstacksdk-in-nova.rst
Normal file
@@ -0,0 +1,278 @@
|
|||||||
|
..
|
||||||
|
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||||
|
License.
|
||||||
|
|
||||||
|
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||||
|
|
||||||
|
|
||||||
|
==========================================
|
||||||
|
Use OpenStack SDK in Nova
|
||||||
|
==========================================
|
||||||
|
|
||||||
|
https://blueprints.launchpad.net/nova/+spec/openstacksdk-in-nova
|
||||||
|
|
||||||
|
We would like to use the OpenStack SDK to interact with other core OpenStack
|
||||||
|
services.
|
||||||
|
|
||||||
|
|
||||||
|
Problem description
|
||||||
|
===================
|
||||||
|
|
||||||
|
Nova is using both ``python-${service}client`` and keystoneauth1 adapters to
|
||||||
|
interact with other core services. Currently changes or fixes to a ``$service``
|
||||||
|
that Nova depends on may require changes to ``python-${service}client`` before
|
||||||
|
Nova can be brought into parity. This also requires the OpenStack SDK to be
|
||||||
|
brought into parity as it is used for the CLI.
|
||||||
|
|
||||||
|
Maintenance of ``python-${service}client`` can be burdensome due to high
|
||||||
|
technical debt in the clients. By consuming the OpenStack SDK directly, we can
|
||||||
|
eliminate the additional dependency on the ``python-${service}client`` and
|
||||||
|
streamline the process.
|
||||||
|
|
||||||
|
Use Cases
|
||||||
|
---------
|
||||||
|
|
||||||
|
As a developer on OpenStack, I would like to reduce the number of areas where
|
||||||
|
maintenance must be performed when making changes related to the use of core
|
||||||
|
OpenStack services.
|
||||||
|
|
||||||
|
As a core OpenStack project, Nova should make use of other projects in reliable
|
||||||
|
and maintainable ways. To this end, we should use the OpenStack SDK for service
|
||||||
|
to service interaction in place of direct API or ``python-${service}client``
|
||||||
|
implementations.
|
||||||
|
|
||||||
|
|
||||||
|
Proposed change
|
||||||
|
===============
|
||||||
|
|
||||||
|
This spec proposes to use the OpenStack SDK in place of
|
||||||
|
``python-${service}client`` and other methods across Nova in three phases for
|
||||||
|
each of the target services.
|
||||||
|
|
||||||
|
Target Services:
|
||||||
|
* Ironic (python-ironicclient -> Baremetal SDK)
|
||||||
|
* Cinder (python-cinderclient -> Block Storage SDK)
|
||||||
|
* Glance (python-glanceclient -> Image v2 SDK)
|
||||||
|
* Neutron (python-neutronclient -> Network SDK)
|
||||||
|
* Placement (keystoneauth1 adapter -> OpenStack SDK Proxy)
|
||||||
|
|
||||||
|
The **initial phase** will consist of adding plumbing to construct an
|
||||||
|
openstack.connection.Connection object to Nova components that interact with
|
||||||
|
other services using a ``python-${service}client``. The service proxy from this
|
||||||
|
connection can then be used in place of existing keystoneauth1 adapter to
|
||||||
|
retrieve the endpoint to configure the client. This is in progress at
|
||||||
|
[[#sdk_in_nova]_].
|
||||||
|
|
||||||
|
The **main phase** will be to iterate through calls to the
|
||||||
|
``python-${service}client`` and replace them with calls into the OpenStack SDK
|
||||||
|
until the client is no longer needed. During this phase, we will close
|
||||||
|
feature deficiencies identified in the OpenStack SDK as necessary. See
|
||||||
|
`OpenStack SDK Changes`_ for a list of identified deficiencies. This process is
|
||||||
|
in progress for ``python-ironicclient`` at [[#sdk_for_ironic]_].
|
||||||
|
|
||||||
|
For Placement, replace the keystoneauth1 adapter returned by
|
||||||
|
``nova.utils.get_ksa_adapter('placement')`` with the SDK's placement proxy.
|
||||||
|
This is transparent other than a small number of changes to mocks in tests.
|
||||||
|
This is in progress at [[#sdk_for_placement]_]. Eventually, the SDK may
|
||||||
|
implement more support for placement. With the framework being in place, we can
|
||||||
|
consider integrating such changes as they become available.
|
||||||
|
|
||||||
|
The **final phase** will simply be to remove the now-unused clients and clean
|
||||||
|
up any remaining helpers and fixtures.
|
||||||
|
|
||||||
|
OpenStack SDK Changes
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
The OpenStack SDK includes a more complete selection of helpers for some
|
||||||
|
services than others, but at worst provides the same primitives as a
|
||||||
|
keystoneauth1 adapter. Development has started with Ironic, which has robust
|
||||||
|
support within the OpenStack SDK. Other services will require additional work
|
||||||
|
in the OpenStack SDK, or may need to be implemented using the API primitives
|
||||||
|
provided by openstack.Proxy. It is more desirable to focus on expanding
|
||||||
|
OpenStack SDK support for these projects rather than implementing them in Nova.
|
||||||
|
Since there is not a spec repo for OpenStack SDK, we will try to outline the
|
||||||
|
missing helpers by service here.
|
||||||
|
|
||||||
|
| **Ironic**
|
||||||
|
| node.get_console
|
||||||
|
| node.inject_nmi
|
||||||
|
| node.list_volume_connectors
|
||||||
|
| node.list_volume_targets
|
||||||
|
| node.set_console_mode (available via ``patch_node``)
|
||||||
|
| volume_target.create
|
||||||
|
| volume_target.delete
|
||||||
|
|
|
||||||
|
| **Cinder**
|
||||||
|
| attachments.complete
|
||||||
|
| attachments.delete
|
||||||
|
| attachments.update
|
||||||
|
| volumes.attach
|
||||||
|
| volumes.begin_detaching
|
||||||
|
| volumes.detach
|
||||||
|
| volumes.initialize_connection
|
||||||
|
| volumes.migrate_volume_completion
|
||||||
|
| volumes.reserve
|
||||||
|
| volumes.roll_detaching
|
||||||
|
| volumes.terminate_connection
|
||||||
|
| volumes.unreserve
|
||||||
|
|
|
||||||
|
| **Glance**
|
||||||
|
| image.add_location
|
||||||
|
|
|
||||||
|
| **Neutron**
|
||||||
|
| None
|
||||||
|
|
||||||
|
Alternatives
|
||||||
|
------------
|
||||||
|
|
||||||
|
One possibility that was considered was to replace calls into
|
||||||
|
``python-${service}client`` with methods that invoke the ``$service`` APIs
|
||||||
|
directly through the keystoneauth1 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.
|
||||||
|
|
||||||
|
Data model impact
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
REST API impact
|
||||||
|
---------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Security impact
|
||||||
|
---------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Notifications impact
|
||||||
|
--------------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Other end user impact
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Performance Impact
|
||||||
|
------------------
|
||||||
|
|
||||||
|
The initial phase will have minimal impact as the only change is the
|
||||||
|
construction of the keystoneauth1 adapter by the OpenStack SDK rather than
|
||||||
|
directly. The main phase will not likely have any difference in performance and
|
||||||
|
the final phase should approximately offset any impact from the initial phase.
|
||||||
|
|
||||||
|
Other deployer impact
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Developer impact
|
||||||
|
----------------
|
||||||
|
|
||||||
|
By using the OpenStack SDK as the single method of contact with other services,
|
||||||
|
the maintenance footprint can be reduced. This also moves us towards a more
|
||||||
|
stable OpenStack SDK as more consumers generally mean more chances to find and
|
||||||
|
resolve bugs.
|
||||||
|
|
||||||
|
In addition, as new methods and services are supported by the OpenStack SDK,
|
||||||
|
introducing them to Nova should be simpler and more reliable than the current
|
||||||
|
methods.
|
||||||
|
|
||||||
|
Upgrade impact
|
||||||
|
--------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
|
||||||
|
Implementation
|
||||||
|
==============
|
||||||
|
|
||||||
|
Assignee(s)
|
||||||
|
-----------
|
||||||
|
|
||||||
|
Primary assignee:
|
||||||
|
dustinc <dustin.cowles@intel.com>, efried <openstack@fried.cc>
|
||||||
|
|
||||||
|
Other contributors:
|
||||||
|
mordred <mordred@inaugust.com>, dtantsur <dtantsur@protonmail.com>
|
||||||
|
|
||||||
|
Work Items
|
||||||
|
----------
|
||||||
|
|
||||||
|
1. Introduce package requirements to Nova.
|
||||||
|
|
||||||
|
2. Introduce plumbing for the construction of an
|
||||||
|
openstack.connection.Connection object for each ``$service``.
|
||||||
|
|
||||||
|
3. For each target ``$service`` (excluding Placement), close
|
||||||
|
deficiencies in OpenStack SDK while replace invocations into
|
||||||
|
``python-${service}client`` one at a time, with calls into the SDK's
|
||||||
|
``$service`` proxy.
|
||||||
|
|
||||||
|
* For Placement, replace the keystoneauth1 adapter with the
|
||||||
|
SDK's placement proxy.
|
||||||
|
|
||||||
|
4. Remove the now-unused ``python-${service}client``, test fixtures, and other
|
||||||
|
helpers and utils.
|
||||||
|
|
||||||
|
|
||||||
|
Dependencies
|
||||||
|
============
|
||||||
|
|
||||||
|
* Nova support for using keystoneauth1 config options for Cinder.
|
||||||
|
|
||||||
|
* https://review.opendev.org/#/c/655985/
|
||||||
|
|
||||||
|
|
||||||
|
Testing
|
||||||
|
=======
|
||||||
|
|
||||||
|
Existing unit tests will need to be updated to assert calls to the SDK instead
|
||||||
|
of the client. In cases where the client call was mocked, this should be a
|
||||||
|
matter of swapping out that mock and its assertions. No significant additional
|
||||||
|
unit testing should be required.
|
||||||
|
|
||||||
|
Existing functional test cases should be adequate. Changes may be required in
|
||||||
|
fixtures and other framework.
|
||||||
|
|
||||||
|
Existing integration tests should continue to function seamlessly. This will be
|
||||||
|
the litmus test of success.
|
||||||
|
|
||||||
|
|
||||||
|
Documentation Impact
|
||||||
|
====================
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
|
||||||
|
References
|
||||||
|
==========
|
||||||
|
|
||||||
|
.. [#sdk_in_nova] https://review.opendev.org/#/c/643664/
|
||||||
|
|
||||||
|
.. [#sdk_for_ironic] https://review.opendev.org/#/c/642899/
|
||||||
|
|
||||||
|
.. [#sdk_for_placement] https://review.opendev.org/#/c/656023/
|
||||||
|
|
||||||
|
.. [#] http://lists.openstack.org/pipermail/openstack-discuss/2019-May/005810.html
|
||||||
|
|
||||||
|
.. [#] https://docs.openstack.org/openstacksdk/latest/user/config/configuration.html
|
||||||
|
|
||||||
|
.. [#] http://eavesdrop.openstack.org/irclogs/%23openstack-sdks/%23openstack-sdks.2019-05-20.log.html#t2019-05-20T13:48:07
|
||||||
|
|
||||||
|
|
||||||
|
History
|
||||||
|
=======
|
||||||
|
|
||||||
|
.. list-table:: Revisions
|
||||||
|
:header-rows: 1
|
||||||
|
|
||||||
|
* - Release Name
|
||||||
|
- Description
|
||||||
|
* - Train
|
||||||
|
- Introduced
|
||||||
Reference in New Issue
Block a user