openstack/oslo-specs
Code Issues Proposed changes

[trivial] minor rephrasing and syntax adjustments

Browse Source 
Change-Id: I2b08d8fca9808d51438cefe972a5f48c71e361b0
This commit is contained in:
Hervé Beraud 2024-11-14 10:39:51 +01:00
parent c458c22c33
commit a14f0734b5
No known key found for this signature in database
GPG Key ID: B0FC62DBFC399289
1 changed files with 14 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
specs/epoxy/remove-eventlet-from-oslo-service.rst
View File

@ -110,7 +110,7 @@ to the future version of oslo.service, a version free from Eventlet.
these features or if we should remove some of them in the process. these features or if we should remove some of them in the process.
If we decide to remove existing feature, then we must decide how transition If we decide to remove existing feature, then we must decide how transition
our customers. our consumers.
In all the case, at some point will would have to release major version of In all the case, at some point will would have to release major version of
oslo.service where the backward compatibility will be definitely broken. oslo.service where the backward compatibility will be definitely broken.
@ -122,21 +122,21 @@ Constraints
For the sake of consistency we have to define a couple of constrains. The For the sake of consistency we have to define a couple of constrains. The
goal of these constraints is to keep the migration as transparent as possible goal of these constraints is to keep the migration as transparent as possible
for customers. for consumers.
* we cannot abruptly remove Eventlet, so, for all the previously described * we cannot abruptly remove Eventlet, so, for all the previously described
oslo.service features, both implementations will have to cohabit, the oslo.service features, both implementations will have to cohabit, the
Eventlet version, and the new one; Eventlet version, and the new one;
* at the oslo.service's customer level, the transition must be as smooth as * at the oslo.service's consumers level, the transition must be as smooth as
possible. Meaning that customer should not have to rewrite all their imports possible. Meaning that consumers should not have to rewrite all their imports
to continue using the Eventlet based implementation, or the new version. to continue using the Eventlet based implementation, or the new version.
Some oslo.service modules may be abandoned, only those imports would have Some oslo.service modules may be abandoned, only those imports would have
to be removed if imported at the customers level; to be removed if imported at the consumers level;
* customers must decide when to switch from an implementation to an other; * consumers must decide when to switch from an implementation to an other;
* the removal of the Eventlet implementation should not impact the customer * the removal of the Eventlet implementation should not impact the consumers
in a random way. If a feature is explicitly removed from oslo.service, then in a random way. If a feature is explicitly removed from oslo.service, then
an alternative must be documented in a migration guide specific to an alternative must be documented in a migration guide specific to
oslo.service. Customers must be informed by deprecation warning of the oslo.service. Customers must be informed by deprecation warning of the
@ -351,9 +351,9 @@ and give instruction to users, example with the wsgi sub-module::
debtcollector.deprecate( debtcollector.deprecate(
""" """
The WSGI module is no longer supported\n The WSGI module is no longer supported
You see this deprecation warning because you are importing\n You see this deprecation warning because you are importing
the oslo.service wsgi module. This module is deprecated and will\n the oslo.service wsgi module. This module is deprecated and will
be soon removed. Please consider using uwsgi and consider following be soon removed. Please consider using uwsgi and consider following
the migration path described here: the migration path described here:
https://docs.openstack.org/oslo.service/latest/migration/wsgi.html https://docs.openstack.org/oslo.service/latest/migration/wsgi.html
@ -375,7 +375,7 @@ re-implemented, then it could remains at the root level. That's by example
the case of the ``systemd`` sub-module, which in our previous tree example the case of the ``systemd`` sub-module, which in our previous tree example
remains at the root level. remains at the root level.
If a customers do not move its oslo.service backend to the ``threading`` If a consumers do not move its oslo.service backend to the ``threading``
backend in the allotted time, then the T.C should be warned. Then the T.C will backend in the allotted time, then the T.C should be warned. Then the T.C will
surely inform the Pop Up team created to manage the whole Eventlet removal. surely inform the Pop Up team created to manage the whole Eventlet removal.
In this case, the Pop Up team may decide to migrate this deliverable or could In this case, the Pop Up team may decide to migrate this deliverable or could
@ -386,7 +386,7 @@ Alternatives
It would be also possible to entirely deprecate oslo.service and to point It would be also possible to entirely deprecate oslo.service and to point
the available alternatives into the deprecation warnings, therefore, the available alternatives into the deprecation warnings, therefore,
leaving the charge of the refactor to the customers. leaving the charge of the refactor to the consumers.
The problem of this approach is that it would surely spring various approaches The problem of this approach is that it would surely spring various approaches
and so a diversity of solution. and so a diversity of solution.
@ -394,7 +394,7 @@ and so a diversity of solution.
The motivation behind the creation of the Oslo projects was to uniformize the The motivation behind the creation of the Oslo projects was to uniformize the
solutions and to reduce the technical debt. solutions and to reduce the technical debt.
If we delegate the refactor to oslo.service customers it will lead to an If we delegate the refactor to oslo.service consumers it will lead to an
increase of this technical debt. increase of this technical debt.
Impact on Existing APIs Impact on Existing APIs
@ -405,7 +405,7 @@ The temporary backends
The existing API will be modified to introduce the temporary backends. The existing API will be modified to introduce the temporary backends.
Backends will remains private module not directly importable Backends will remains private module not directly importable
by customers. One or the other backend will be imported by the classic by consumers. One or the other backend will be imported by the classic
import and by choosing one backend or the other in the config. import and by choosing one backend or the other in the config.
The public API will remains almost the same until the Eventlet backend is not The public API will remains almost the same until the Eventlet backend is not