
Adds the capability to utilize the indirection API model. The vast majority of this change is the removal of legacy comments and the swap of decorators on object methods to allow the Versioned Objects Indirection API to route the calls upon objects through the RPC layer to the conductor. In order to make these calls occur, we need to also send along a context, which is required to call the RPC layer, which is fine. Original tests still work in that API surface calls still ultimately trigger DB API calls in the backend, thus test changes are actually minimal, similar to very slight changes in trait retrieval as well. In that we really can't nest objects across the indirection layer. Change-Id: Ia161fef67b8a116fdf7cad9b2e559ba75263e196 Signed-off-by: Julia Kreger <juliaashleykreger@gmail.com>
24 lines
1.1 KiB
YAML
24 lines
1.1 KiB
YAML
---
|
|
features:
|
|
- |
|
|
Adds the capability for the Ironic API services to operate without
|
|
a direct connection to the Ironic database backend. Instead the
|
|
RPC Object model through the concept of remotable objects.
|
|
The ``[default]use_rpc_for_database`` setting can be utilized to
|
|
leverage this mode of operation, however it is also implied when
|
|
the ``[default]rpc_transport`` option is set to ``none`` or ``local``.
|
|
upgrade:
|
|
- |
|
|
The introduction of the capability to utilize remotable objects with
|
|
the API has resulted in object versions internally being incremented
|
|
without actual schema changes. This may result in an upgrade taking
|
|
a little longer, depending on the size of the database,
|
|
as object versions are updated during the upgrade sequence.
|
|
deprecations:
|
|
- |
|
|
Use of the API DBHook feature, i.e. the resulting ``api.request.dbapi``
|
|
pattern in API service code is deprecated and the DBHook will be removed
|
|
in a future release of Ironic. Any downstream maintainers which utilize
|
|
this pattern are encouraged to utilize an object to serve as an
|
|
intermediary stepping stone between the API and the database.
|