598314a4bb
Change If1e03c9343b8cc9c34bd51c2b4d25acdb21131ff made the "PUT /os-services/*" APIs only work with nova-compute services since they now rely on finding the compute service in a cell via the host_mappings record in the API database, and host mappings only exist for compute services. No one should have relied on disabling a non-compute service since that does nothing, at least with in-tree code. This change just adds a release note for awareness. Change-Id: Idb5bbc31a0aabc328f11e5a9979e5b80651a8f67 Closes-Bug: #1700359
16 lines
842 B
YAML
16 lines
842 B
YAML
---
|
|
other:
|
|
- |
|
|
The ``PUT /os-services/disable``, ``PUT /os-services/enable`` and
|
|
``PUT /os-services/force-down`` APIs to enable, disable, or force-down a
|
|
service will now only work with *nova-compute* services. If you are using
|
|
those APIs to try and disable a non-compute service, like nova-scheduler or
|
|
nova-conductor, those APIs will result in a 404 response.
|
|
|
|
There really never was a good reason to disable or enable non-compute
|
|
services anyway since that would not do anything. The nova-scheduler and
|
|
nova-api services are checking the ``status`` and ``forced_down`` fields to
|
|
see if instance builds can be scheduled to a compute host or if instances
|
|
can be evacuated from a downed compute host. There is nothing that relies
|
|
on a disabled or downed nova-conductor or nova-scheduler service.
|