Merge "Correct indent in doc"
This commit is contained in:
Zuul
Gerrit Code Review
commit
0fbd7a427d
|
|
@ -36,24 +36,24 @@ Major Components
|
|||
In the context of an OpenStack cloud, the most important components involved in
|
||||
the authentication and the authorization process are:
|
||||
|
||||
- The Senlin client (i.e. the `python-senlinclient` package) which accepts
|
||||
user credentials provided through environment variables and/or the command
|
||||
line arguments and forwards them to the OpenStack SDK (i.e. the
|
||||
`python-openstacksdk` package) when making service requests to Senlin API.
|
||||
- The OpenStack SDK (`python-openstacksdk`) is used by Senlin engine to
|
||||
interact with any other OpenStack services. The Senlin client also uses the
|
||||
SDK to talk to the Senlin API. The SDK package translates the user-provided
|
||||
credentials into a token by invoking the Keystone service.
|
||||
- The Keystone middleware (i.e. `keystonemiddleware`) which backs the
|
||||
`auth_token` WSGI middleware in the Senlin API pipeline provides a basic
|
||||
validation filter. The filter is responsible to validate the token that
|
||||
exists in the HTTP request header and then populates the HTTP request header
|
||||
with detailed information for the downstream filters (including the API
|
||||
itself) to use.
|
||||
- The `context` WSGI middleware which is based on the `oslo.context` package
|
||||
provides a constructor of the `RequestContext` data structure that
|
||||
accompanies any requests down the WSGI application pipeline so that those
|
||||
downstream components don't have to access the HTTP request header.
|
||||
- The Senlin client (i.e. the `python-senlinclient` package) which accepts
|
||||
user credentials provided through environment variables and/or the command
|
||||
line arguments and forwards them to the OpenStack SDK (i.e. the
|
||||
`python-openstacksdk` package) when making service requests to Senlin API.
|
||||
- The OpenStack SDK (`python-openstacksdk`) is used by Senlin engine to
|
||||
interact with any other OpenStack services. The Senlin client also uses the
|
||||
SDK to talk to the Senlin API. The SDK package translates the user-provided
|
||||
credentials into a token by invoking the Keystone service.
|
||||
- The Keystone middleware (i.e. `keystonemiddleware`) which backs the
|
||||
`auth_token` WSGI middleware in the Senlin API pipeline provides a basic
|
||||
validation filter. The filter is responsible to validate the token that
|
||||
exists in the HTTP request header and then populates the HTTP request header
|
||||
with detailed information for the downstream filters (including the API
|
||||
itself) to use.
|
||||
- The `context` WSGI middleware which is based on the `oslo.context` package
|
||||
provides a constructor of the `RequestContext` data structure that
|
||||
accompanies any requests down the WSGI application pipeline so that those
|
||||
downstream components don't have to access the HTTP request header.
|
||||
|
||||
|
||||
Usage Scenarios
|
||||
|
|
|
|||
|
|
@ -29,11 +29,11 @@ Keystone project (tenant) which is the default project of the user.
|
|||
|
||||
A cluster has the following timestamps when instantiated:
|
||||
|
||||
- ``init_at``: the timestamp when a cluster object is initialized in the
|
||||
Senlin database, but the actual cluster creation has not yet started;
|
||||
- ``created_at``: the timestamp when the cluster object is created, i.e.
|
||||
the ``CLUSTER_CREATE`` action has completed;
|
||||
- ``updated_at``: the timestamp when the cluster was last updated.
|
||||
- ``init_at``: the timestamp when a cluster object is initialized in the
|
||||
Senlin database, but the actual cluster creation has not yet started;
|
||||
- ``created_at``: the timestamp when the cluster object is created, i.e.
|
||||
the ``CLUSTER_CREATE`` action has completed;
|
||||
- ``updated_at``: the timestamp when the cluster was last updated.
|
||||
|
||||
|
||||
Cluster Statuses
|
||||
|
|
@ -41,20 +41,20 @@ Cluster Statuses
|
|||
|
||||
A cluster can have one of the following statuses during its lifecycle:
|
||||
|
||||
- ``INIT``: the cluster object has been initialized, but not created yet;
|
||||
- ``ACTIVE``: the cluster is created and providing service;
|
||||
- ``CREATING``: the cluster creation action is still on going;
|
||||
- ``ERROR``: the cluster is still providing services, but there are things
|
||||
going wrong that needs human intervention;
|
||||
- ``CRITICAL``: the cluster is not operational, it may or may not be
|
||||
providing services as expected. Senlin cannot recover it from its current
|
||||
status. The best way to deal with this cluster is to delete it and then
|
||||
re-create it if needed.
|
||||
- ``DELETING``: the cluster deletion is ongoing;
|
||||
- ``WARNING``: the cluster is operational, but there are some warnings
|
||||
detected during past operations. In this case, human involvement is
|
||||
suggested but not required.
|
||||
- ``UPDATING``: the cluster is being updated.
|
||||
- ``INIT``: the cluster object has been initialized, but not created yet;
|
||||
- ``ACTIVE``: the cluster is created and providing service;
|
||||
- ``CREATING``: the cluster creation action is still on going;
|
||||
- ``ERROR``: the cluster is still providing services, but there are things
|
||||
going wrong that needs human intervention;
|
||||
- ``CRITICAL``: the cluster is not operational, it may or may not be
|
||||
providing services as expected. Senlin cannot recover it from its current
|
||||
status. The best way to deal with this cluster is to delete it and then
|
||||
re-create it if needed.
|
||||
- ``DELETING``: the cluster deletion is ongoing;
|
||||
- ``WARNING``: the cluster is operational, but there are some warnings
|
||||
detected during past operations. In this case, human involvement is
|
||||
suggested but not required.
|
||||
- ``UPDATING``: the cluster is being updated.
|
||||
|
||||
Along with the ``status`` property, Senlin provides a ``status_reason``
|
||||
property for users to check what is the cause of the cluster's current status.
|
||||
|
|
@ -74,24 +74,24 @@ carries a body with valid, sufficient information for the engine to complete
|
|||
the creation job. The following fields are required in a map named ``cluster``
|
||||
in the request JSON body:
|
||||
|
||||
- ``name``: the name of the cluster to be created;
|
||||
- ``profile``: the name or ID or short-ID of a profile to be used;
|
||||
- ``desired_capacity``: the desired number of nodes in the cluster, which is
|
||||
treated also as the initial number of nodes to be created.
|
||||
- ``name``: the name of the cluster to be created;
|
||||
- ``profile``: the name or ID or short-ID of a profile to be used;
|
||||
- ``desired_capacity``: the desired number of nodes in the cluster, which is
|
||||
treated also as the initial number of nodes to be created.
|
||||
|
||||
The following optional fields can be provided in the ``cluster`` map in the
|
||||
JSON request body:
|
||||
|
||||
- ``min_size``: the minimum number of nodes inside the cluster, default
|
||||
value is 0;
|
||||
- ``max_size``: the maximum number of nodes inside the cluster, default
|
||||
value is -1, which means there is no upper limit on the number of nodes;
|
||||
- ``timeout``: the maximum number of seconds to wait for the cluster to
|
||||
become ready, i.e. ``ACTIVE``.
|
||||
- ``metadata``: a list of key-value pairs to be associated with the cluster.
|
||||
- ``dependents``: A dict contains dependency information between nova server/
|
||||
heat stack cluster and container cluster. The container node's id will be
|
||||
stored in 'dependents' property of its host cluster.
|
||||
- ``min_size``: the minimum number of nodes inside the cluster, default
|
||||
value is 0;
|
||||
- ``max_size``: the maximum number of nodes inside the cluster, default
|
||||
value is -1, which means there is no upper limit on the number of nodes;
|
||||
- ``timeout``: the maximum number of seconds to wait for the cluster to
|
||||
become ready, i.e. ``ACTIVE``.
|
||||
- ``metadata``: a list of key-value pairs to be associated with the cluster.
|
||||
- ``dependents``: A dict contains dependency information between nova server/
|
||||
heat stack cluster and container cluster. The container node's id will be
|
||||
stored in 'dependents' property of its host cluster.
|
||||
|
||||
The ``max_size`` and the ``min_size`` fields, when specified, will be checked
|
||||
against each other by the Senlin API. The API also checks if the specified
|
||||
|
|
|
|||
|
|
@ -15,12 +15,12 @@
|
|||
OSProfiler
|
||||
==========
|
||||
|
||||
OSProfiler provides a tiny but powerful library that is used by
|
||||
most (soon to be all) OpenStack projects and their python clients. It
|
||||
provides functionality to be able to generate 1 trace per request, that goes
|
||||
through all involved services. This trace can then be extracted and used
|
||||
to build a tree of calls which can be quite handy for a variety of
|
||||
reasons (for example in isolating cross-project performance issues).
|
||||
OSProfiler provides a tiny but powerful library that is used by
|
||||
most (soon to be all) OpenStack projects and their python clients. It
|
||||
provides functionality to be able to generate 1 trace per request, that goes
|
||||
through all involved services. This trace can then be extracted and used
|
||||
to build a tree of calls which can be quite handy for a variety of
|
||||
reasons (for example in isolating cross-project performance issues).
|
||||
|
||||
More about OSProfiler:
|
||||
https://docs.openstack.org/osprofiler/latest/
|
||||
|
|
|
|||
|
|
@ -141,10 +141,10 @@ policy file, copy it to `/etc/senlin/policy.yaml` and then update it.
|
|||
|
||||
5. Create Senlin Database.
|
||||
|
||||
Create Senlin database using the :command:`senlin-db-recreate` script under
|
||||
the :file:`tools` subdirectory. Before calling the script, you need edit it
|
||||
to customize the password you will use for the ``senlin`` user. You need to
|
||||
update this script with the <DB PASSWORD> entered in step4.
|
||||
Create Senlin database using the :command:`senlin-db-recreate` script under
|
||||
the :file:`tools` subdirectory. Before calling the script, you need edit it
|
||||
to customize the password you will use for the ``senlin`` user. You need to
|
||||
update this script with the <DB PASSWORD> entered in step4.
|
||||
|
||||
::
|
||||
|
||||
|
|
@ -153,7 +153,7 @@ policy file, copy it to `/etc/senlin/policy.yaml` and then update it.
|
|||
|
||||
6. Start senlin engine and api service.
|
||||
|
||||
You may need two consoles for the services i.e., one for each service.
|
||||
You may need two consoles for the services i.e., one for each service.
|
||||
|
||||
::
|
||||
|
||||
|
|
|
|||
|
|
@ -35,11 +35,11 @@ Senlin DB version
|
|||
|
||||
``senlin-manage db_version``
|
||||
|
||||
Print out the db schema revision.
|
||||
Print out the db schema revision.
|
||||
|
||||
``senlin-manage db_sync``
|
||||
|
||||
Sync the database up to the most recent version.
|
||||
Sync the database up to the most recent version.
|
||||
|
||||
|
||||
FILES
|
||||
|
|
|
|||
|
|
@ -10,91 +10,91 @@ it can be used by both users and developers.
|
|||
1.1
|
||||
---
|
||||
|
||||
- This is the initial version of the v1 API which supports microversions.
|
||||
The v1.1 API is identical to that of v1.0 except for the new supports to
|
||||
microversion checking.
|
||||
- This is the initial version of the v1 API which supports microversions.
|
||||
The v1.1 API is identical to that of v1.0 except for the new supports to
|
||||
microversion checking.
|
||||
|
||||
A user can specify a header in the API request::
|
||||
A user can specify a header in the API request::
|
||||
|
||||
OpenStack-API-Version: clustering <version>
|
||||
OpenStack-API-Version: clustering <version>
|
||||
|
||||
where the ``<version>`` is any valid API version supported. If such a
|
||||
header is not provided, the API behaves as if a version request of v1.0
|
||||
is received.
|
||||
where the ``<version>`` is any valid API version supported. If such a
|
||||
header is not provided, the API behaves as if a version request of v1.0
|
||||
is received.
|
||||
|
||||
1.2
|
||||
---
|
||||
|
||||
- Added ``cluster_collect`` API. This API takes a single parameter ``path``
|
||||
and interprets it as a JSON path for extracting node properties. Properties
|
||||
values from all nodes are aggregated into a list and returned to users.
|
||||
- Added ``cluster_collect`` API. This API takes a single parameter ``path``
|
||||
and interprets it as a JSON path for extracting node properties. Properties
|
||||
values from all nodes are aggregated into a list and returned to users.
|
||||
|
||||
- Added ``profile_validate`` API. This API is provided to validate the spec
|
||||
of a profile without really creating a profile object.
|
||||
- Added ``profile_validate`` API. This API is provided to validate the spec
|
||||
of a profile without really creating a profile object.
|
||||
|
||||
- Added ``policy_validate`` API. This API validates the spec of a policy
|
||||
without creating a policy object.
|
||||
- Added ``policy_validate`` API. This API validates the spec of a policy
|
||||
without creating a policy object.
|
||||
|
||||
1.3
|
||||
---
|
||||
|
||||
- Added ``cluster_replace_nodes`` API. This API enables users to replace the
|
||||
specified existing nodes with ones that were not members of any clusters.
|
||||
- Added ``cluster_replace_nodes`` API. This API enables users to replace the
|
||||
specified existing nodes with ones that were not members of any clusters.
|
||||
|
||||
1.4
|
||||
---
|
||||
|
||||
- Added ``profile_type_ops`` API. This API returns a dictionary containing
|
||||
the operations and parameters supported by a specific profile type.
|
||||
- Added ``profile_type_ops`` API. This API returns a dictionary containing
|
||||
the operations and parameters supported by a specific profile type.
|
||||
|
||||
- Added ``node_operation`` API. This API enables users to trigger an
|
||||
operation on a node. The operation and its parameters are determined by the
|
||||
profile type.
|
||||
- Added ``node_operation`` API. This API enables users to trigger an
|
||||
operation on a node. The operation and its parameters are determined by the
|
||||
profile type.
|
||||
|
||||
- Added ``cluster_operation`` API. This API enables users to trigger an
|
||||
operation on a cluster. The operation and its parameters are determined by
|
||||
the profile type.
|
||||
- Added ``cluster_operation`` API. This API enables users to trigger an
|
||||
operation on a cluster. The operation and its parameters are determined by
|
||||
the profile type.
|
||||
|
||||
- Added ``user`` query parameter for listing receivers.
|
||||
- Added ``user`` query parameter for listing receivers.
|
||||
|
||||
- Added ``destroy_after_deletion`` parameter for deleting cluster members.
|
||||
- Added ``destroy_after_deletion`` parameter for deleting cluster members.
|
||||
|
||||
1.5
|
||||
---
|
||||
|
||||
- Added ``support_status`` to profile type list.
|
||||
- Added ``support_status`` to profile type list.
|
||||
|
||||
- Added ``support_status`` to policy type list.
|
||||
- Added ``support_status`` to policy type list.
|
||||
|
||||
- Added ``support_status`` to profile type show.
|
||||
- Added ``support_status`` to profile type show.
|
||||
|
||||
- Added ``support_status`` to policy type show.
|
||||
- Added ``support_status`` to policy type show.
|
||||
|
||||
1.6
|
||||
---
|
||||
|
||||
- Added ``profile_only`` parameter to cluster update request.
|
||||
- Added ``profile_only`` parameter to cluster update request.
|
||||
|
||||
- Added ``check`` parameter to node recover request. When this parameter is
|
||||
specified, the engine will check if the node is active before performing
|
||||
a recover operation.
|
||||
- Added ``check`` parameter to node recover request. When this parameter is
|
||||
specified, the engine will check if the node is active before performing
|
||||
a recover operation.
|
||||
|
||||
- Added ``check`` parameter to cluster recover request. When this parameter
|
||||
is specified, the engine will check if the nodes are active before
|
||||
performing a recover operation.
|
||||
- Added ``check`` parameter to cluster recover request. When this parameter
|
||||
is specified, the engine will check if the nodes are active before
|
||||
performing a recover operation.
|
||||
|
||||
1.7
|
||||
---
|
||||
|
||||
- Added ``node_adopt`` operation to node.
|
||||
- Added ``node_adopt`` operation to node.
|
||||
|
||||
- Added ``node_adopt_preview`` operation to node.
|
||||
- Added ``node_adopt_preview`` operation to node.
|
||||
|
||||
- Added ``receiver_update`` operation to receiver.
|
||||
- Added ``receiver_update`` operation to receiver.
|
||||
|
||||
- Added ``service_list`` API.
|
||||
- Added ``service_list`` API.
|
||||
|
||||
1.8
|
||||
---
|
||||
- Added ``force`` parameter to cluster delete request.
|
||||
- Added ``force`` parameter to node delete request.
|
||||
- Added ``force`` parameter to cluster delete request.
|
||||
- Added ``force`` parameter to node delete request.
|
||||
|
|
|
|||
Loading…
Reference in New Issue