Merge "Status attributes in the resource model"
This commit is contained in:
commit
2ab76ffd72
|
@ -0,0 +1,249 @@
|
||||||
|
..
|
||||||
|
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||||
|
License.
|
||||||
|
|
||||||
|
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||||
|
|
||||||
|
==========================================
|
||||||
|
Status for GBP Resources
|
||||||
|
==========================================
|
||||||
|
|
||||||
|
Launchpad blueprint:
|
||||||
|
|
||||||
|
https://blueprints.launchpad.net/group-based-policy/+spec/resource-status
|
||||||
|
|
||||||
|
|
||||||
|
Problem description
|
||||||
|
===================
|
||||||
|
|
||||||
|
GBP supports a configurable Policy Driver based design. Rendering of the GBP
|
||||||
|
policy model can be performed by the Policy Driver in an asynchronous manner.
|
||||||
|
However, currently there is no mechanism to reflect the state of a particular
|
||||||
|
resource while it's being rendered and/or after its successful completion or
|
||||||
|
failure. This requirement has also come up in the context of the service chain
|
||||||
|
support [#]_.
|
||||||
|
|
||||||
|
|
||||||
|
Proposed change
|
||||||
|
===============
|
||||||
|
|
||||||
|
Reflecting the operational state of a resource is typically achieved in
|
||||||
|
OpenStack projects by maintaining a ``status`` attribute [#]_ [#]_.
|
||||||
|
|
||||||
|
The status value will reflect one of the following states:
|
||||||
|
|
||||||
|
ACTIVE: The backend state of the resource is healthy and the user should expect
|
||||||
|
the configured state of the resource to be in effect
|
||||||
|
|
||||||
|
ERROR: The backend state of the resource is in error and the user should not
|
||||||
|
expect this resource to be operational
|
||||||
|
|
||||||
|
BUILD: The backend state of the resource is transient and may not be
|
||||||
|
operational but not in error state
|
||||||
|
|
||||||
|
The state transition diagram for the above states is as follows:
|
||||||
|
|
||||||
|
::
|
||||||
|
|
||||||
|
+-----------+
|
||||||
|
+----------+ +--------+
|
||||||
|
| | BUILD | |
|
||||||
|
| +----> <--+ |
|
||||||
|
| | +-----------+ | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
+--v-----+---+ +----+-----v-+
|
||||||
|
| +----------> |
|
||||||
|
| ERROR | | ACTIVE |
|
||||||
|
| <----------+ |
|
||||||
|
+------------+ +------------+
|
||||||
|
|
||||||
|
In addition to the status attribute it is proposed to also add a
|
||||||
|
``status_details`` attribute. This will be a free form string of a reasonable
|
||||||
|
length that provides more granular and likely more backend-specific information
|
||||||
|
about the status.
|
||||||
|
|
||||||
|
Both ``status`` and ``status_details`` attributes will be read-only attributes
|
||||||
|
in the API and updated only by the internal implementation.
|
||||||
|
|
||||||
|
For backward compatibility, we will allow these two attributes to be set to
|
||||||
|
None. When this attribute is not set, it implies that the backend
|
||||||
|
implementation does not support the ``status`` attribute.
|
||||||
|
|
||||||
|
The changes in the backend state of a resource could be either provided by an
|
||||||
|
asynchronouse update (by the backend), or could be pulled on demand. In the
|
||||||
|
latter case, there needs to be a trigger to initiate the pull. The GET request
|
||||||
|
on a resource can serve as this trigger. However, in the current framework,
|
||||||
|
the GET request is satisfied by the plugin layer, and not relayed to the
|
||||||
|
policy driver(s). This spec proposes an update to the policy driver API which
|
||||||
|
will allow relaying the GET request the drivers.
|
||||||
|
|
||||||
|
It should be noted that if the status needs to be composed by multiple drivers,
|
||||||
|
this would be the responsibility of the participating drivers. The framework
|
||||||
|
changes proposed here would allow the status changes to be passed sequentially
|
||||||
|
between the configured drivers (in the same way that a context is passed for
|
||||||
|
the CREATE, UPDATE, and DELETE calls).
|
||||||
|
|
||||||
|
If the status, after invoking the last driver in the chain of drivers, is
|
||||||
|
different from the persisted status, the persisted status is updated
|
||||||
|
accordingly and made available to the caller.
|
||||||
|
|
||||||
|
|
||||||
|
Data model impact
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
The new attributes will be modeled in the DB as follows:
|
||||||
|
|
||||||
|
::
|
||||||
|
|
||||||
|
import sqlalchemy as sa
|
||||||
|
|
||||||
|
sa.Column('status', sa.Enum('active', 'build', 'error',
|
||||||
|
name='resource_status'), nullable=True)
|
||||||
|
|
||||||
|
sa.Column('status_details', sa.String(length=4096), nullable=True)
|
||||||
|
|
||||||
|
|
||||||
|
REST API impact
|
||||||
|
---------------
|
||||||
|
|
||||||
|
The following update will be made to each resource's attribute map definition:
|
||||||
|
|
||||||
|
::
|
||||||
|
|
||||||
|
'status': {'allow_post': False, 'allow_put': False,
|
||||||
|
'is_visible': True},
|
||||||
|
'status_details': {'allow_post': False, 'allow_put': False,
|
||||||
|
'is_visible': True},
|
||||||
|
|
||||||
|
Security impact
|
||||||
|
---------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
|
||||||
|
Notifications impact
|
||||||
|
--------------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
|
||||||
|
Other end user impact
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
|
||||||
|
Performance impact
|
||||||
|
------------------
|
||||||
|
|
||||||
|
None anticipated.
|
||||||
|
|
||||||
|
|
||||||
|
Other deployer impact
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
Mitaka GBP client will be needed to read resource status.
|
||||||
|
|
||||||
|
Developer impact
|
||||||
|
----------------
|
||||||
|
|
||||||
|
Policy driver implementation should appropriately set the status for GBP
|
||||||
|
resources.
|
||||||
|
|
||||||
|
The following API calls will be added to the Policy Driver API:
|
||||||
|
|
||||||
|
::
|
||||||
|
def get_<resource>_status(self, <resource_context>):
|
||||||
|
|
||||||
|
As is the cases with CREATE, UPDATE, DELETE operations, the GBP Plugin will
|
||||||
|
sequentially call the configured drivers with this API in response to a GET
|
||||||
|
call. The initial <resource_context> is created with the state of the resource
|
||||||
|
stored in the DB, and subsequently the <resource_context> processed by each
|
||||||
|
policy driver is passed to the subsequently configured policy driver.
|
||||||
|
|
||||||
|
Community impact
|
||||||
|
----------------
|
||||||
|
|
||||||
|
Helps to achieve asynchronous behavior with GBP API.
|
||||||
|
|
||||||
|
|
||||||
|
Alternatives
|
||||||
|
------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
|
||||||
|
Implementation
|
||||||
|
==============
|
||||||
|
|
||||||
|
The initial patch will only update the GBP resource and DB model. The
|
||||||
|
setting of resource status will be implemented in the planned asynchronous
|
||||||
|
policy driver [#]_.
|
||||||
|
|
||||||
|
Client will be updated to report status attributes. Updates to UI and Heat will be
|
||||||
|
performed as follow up patches.
|
||||||
|
|
||||||
|
Assignee(s)
|
||||||
|
-----------
|
||||||
|
|
||||||
|
snaiksat
|
||||||
|
|
||||||
|
|
||||||
|
Work items
|
||||||
|
----------
|
||||||
|
|
||||||
|
API and DB layer updates to GBP Resources. Service Chain resources will also be
|
||||||
|
updated. Changes to the Service Chain driver will need to be handled
|
||||||
|
separately.
|
||||||
|
|
||||||
|
|
||||||
|
Dependencies
|
||||||
|
============
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
|
||||||
|
Testing
|
||||||
|
=======
|
||||||
|
|
||||||
|
Relevant UTs will be added.
|
||||||
|
|
||||||
|
Tempest Tests
|
||||||
|
-------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
|
||||||
|
Functional Tests
|
||||||
|
----------------
|
||||||
|
|
||||||
|
Functional tests will be added in follow up patches (as the policy drivers
|
||||||
|
start populating the status).
|
||||||
|
|
||||||
|
|
||||||
|
API Tests
|
||||||
|
---------
|
||||||
|
|
||||||
|
UTs
|
||||||
|
|
||||||
|
|
||||||
|
Documentation impact
|
||||||
|
====================
|
||||||
|
|
||||||
|
User Documentation
|
||||||
|
------------------
|
||||||
|
|
||||||
|
Will provided with the new async policy driver.
|
||||||
|
|
||||||
|
|
||||||
|
Developer Documentation
|
||||||
|
-----------------------
|
||||||
|
|
||||||
|
Devref document will be added.
|
||||||
|
|
||||||
|
References
|
||||||
|
==========
|
||||||
|
|
||||||
|
.. [#] https://bugs.launchpad.net/group-based-policy/+bug/1479706
|
||||||
|
.. [#] https://github.com/openstack/neutron/blob/master/neutron/common/constants.py#L18-L26
|
||||||
|
.. [#] http://docs.openstack.org/developer/nova/vmstates.html
|
||||||
|
.. [#] https://blueprints.launchpad.net/group-based-policy/+spec/async-policy-driver
|
Loading…
Reference in New Issue