Files
045d883772108c722e2a483a6e6b3239d4518a05
nova /api-ref /source /os-services.inc

356 lines
9.2 KiB
PHP
Raw Normal View History

Compute services (os-services)
================================
For an overview of Compute services, see `OpenStack
List Compute Services
=====================
Normal response codes: 200
-------
.. rest_parameters:: parameters.yaml
- binary: binary_query
- host: host_query_service
.. rest_parameters:: parameters.yaml
- services: services
- id: service_id_body_2_53
- host: host_name_body
- zone: OS-EXT-AZ:availability_zone
========================================
Specify the service by its host name and binary name.
``PUT /os-services/{service_id}``.
Request
.. rest_parameters:: parameters.yaml
Response
.. rest_parameters:: parameters.yaml
- service: service
- binary: binary
================================================================
service table about why a Compute service was disabled.
Specify the service by its host name and binary name.
``PUT /os-services/{service_id}``.
Request
.. rest_parameters:: parameters.yaml
Response
.. rest_parameters:: parameters.yaml
- service: service
- binary: binary
- host: host_name_body
=======================================
Specify the service by its host name and binary name.
``PUT /os-services/{service_id}``.
Request
.. rest_parameters:: parameters.yaml
Response
.. rest_parameters:: parameters.yaml
- service: service
- binary: binary
:language: javascript
Update Forced Down
==================
.. rest_method:: PUT /os-services/force-down
Set or unset ``forced_down`` flag for the service. ``forced_down`` is a manual
override to tell nova that the service in question has been fenced manually by
the operations team (either hard powered off, or network unplugged). That
signals that it is safe to proceed with ``evacuate`` or other operations that
nova has safety checks to prevent for hosts that are up.
.. warning::
Setting a service forced down without completely fencing it will likely
result in the corruption of VMs on that host.
Action ``force-down`` available as of microversion 2.11.
Specify the service by its host name and binary name.
``PUT /os-services/{service_id}``.
Error response codes: badRequest(400), unauthorized(401), forbidden(403), itemNotFound(404)
Request
-------
.. rest_parameters:: parameters.yaml
- host: host_name_body
- binary: binary
**Example Update Forced Down**
.. literalinclude:: ../../doc/api_samples/os-services/v2.11/service-force-down-put-req.json
:language: javascript
Response
--------
.. rest_parameters:: parameters.yaml
- service: service
- binary: binary
- host: host_name_body
|
**Example Update Forced Down**
.. literalinclude:: ../../doc/api_samples/os-services/v2.11/service-force-down-put-resp.json
======================
.. rest_method:: PUT /os-services/{service_id}
Update a compute service to enable or disable scheduling, including recording a
reason why a compute service was disabled from scheduling. Set or unset the
``forced_down`` flag for the service.
This API is available starting with microversion 2.53.
Normal response codes: 200
Error response codes: badRequest(400), unauthorized(401), forbidden(403), itemNotFound(404)
Request
-------
.. rest_parameters:: parameters.yaml
- service_id: service_id_path_2_53_no_version
- status: service_status_2_53_in
- disabled_reason: disabled_reason_2_53_in
- forced_down: forced_down_2_53_in
**Example Disable Scheduling For A Compute Service (v2.53)**
.. literalinclude:: ../../doc/api_samples/os-services/v2.53/service-disable-log-put-req.json
:language: javascript
**Example Enable Scheduling For A Compute Service (v2.53)**
.. literalinclude:: ../../doc/api_samples/os-services/v2.53/service-enable-put-req.json
:language: javascript
**Example Update Forced Down (v2.53)**
.. literalinclude:: ../../doc/api_samples/os-services/v2.53/service-force-down-put-req.json
:language: javascript
Response
--------
.. rest_parameters:: parameters.yaml
- service: service
- id: service_id_body_2_53_no_version
- binary: binary
- disabled_reason: disabled_reason_body
- host: host_name_body
- state: service_state
- status: service_status
- updated_at: updated
- zone: OS-EXT-AZ:availability_zone
- forced_down: forced_down_2_53_out
**Example Disable Scheduling For A Compute Service (v2.53)**
.. literalinclude:: ../../doc/api_samples/os-services/v2.53/service-disable-log-put-resp.json
:language: javascript
**Example Enable Scheduling For A Compute Service (v2.53)**
.. literalinclude:: ../../doc/api_samples/os-services/v2.53/service-enable-put-resp.json
:language: javascript
**Example Update Forced Down (v2.53)**
.. literalinclude:: ../../doc/api_samples/os-services/v2.53/service-force-down-put-resp.json
:language: javascript
======================
Block deleting compute services which are hosting instances This change makes "DELETE /os-services/{service_id}" fail with a 409 response when attempting to delete a nova-compute service which is still hosting instances. Deleting a compute service also results in deleting the related compute_nodes table entry for that service host. The compute node resource provider in placement is tied to the compute node via the UUID, and if we allow deleting the compute service and node then the resource provider for that node is effectively orphaned in Placement, along with the instances which have allocations against that resource provider. Furthermore, restarting the compute service will create a new service and compute_nodes record, and the compute node would have a new UUID and resource provider. This will affect scheduling for that host since Placement will be reporting it as having available capacity which in reality is not accurate. A release note is included for the (justified) behavior change in the API. A new microversion should not be required for this since admins should not have to opt out of broken behavior. Since this API did not previously expect to return a 409 response, the "expected_errors" decorator is updated and again, should not require a microversion per the guidelines: https://docs.openstack.org/nova/latest/contributor/microversions.html#when-a-microversion-is-not-needed Change-Id: I0bd63b655ad3d3d39af8d15c781ce0a45efc8e3a Closes-Bug: #1763183
2018年04月11日 18:00:39 -04:00
Attempts to delete a ``nova-compute`` service which is still hosting instances
will result in a 409 HTTPConflict response. The instances will need to be
migrated or deleted before a compute service can be deleted.
physical host *before* deleting the service with this API.
Failing to do so can lead to the running service re-creating
orphaned **compute_nodes** table records in the database.
Block deleting compute services which are hosting instances This change makes "DELETE /os-services/{service_id}" fail with a 409 response when attempting to delete a nova-compute service which is still hosting instances. Deleting a compute service also results in deleting the related compute_nodes table entry for that service host. The compute node resource provider in placement is tied to the compute node via the UUID, and if we allow deleting the compute service and node then the resource provider for that node is effectively orphaned in Placement, along with the instances which have allocations against that resource provider. Furthermore, restarting the compute service will create a new service and compute_nodes record, and the compute node would have a new UUID and resource provider. This will affect scheduling for that host since Placement will be reporting it as having available capacity which in reality is not accurate. A release note is included for the (justified) behavior change in the API. A new microversion should not be required for this since admins should not have to opt out of broken behavior. Since this API did not previously expect to return a 409 response, the "expected_errors" decorator is updated and again, should not require a microversion per the guidelines: https://docs.openstack.org/nova/latest/contributor/microversions.html#when-a-microversion-is-not-needed Change-Id: I0bd63b655ad3d3d39af8d15c781ce0a45efc8e3a Closes-Bug: #1763183
2018年04月11日 18:00:39 -04:00
Error response codes: badRequest(400), unauthorized(401), forbidden(403),
itemNotFound(404), conflict(409)
Request
.. rest_parameters:: parameters.yaml
- service_id: service_id_path_2_53
Response