With this change in Pike:
https://review.openstack.org/#/c/442162/
The PUT /os-services/* APIs to enable/disable/force-down a service will
now only work with nova-compute services. If you're using those to try
and disable a non-compute service, like nova-scheduler or
nova-conductor, those APIs will result in a 404 response because there
won't be host mappings for non-compute services.
There really never was a good reason to disable/enable non-compute
services anyway since it wouldn't do anything. The scheduler and API 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 conductor or scheduler service.
I realize the docs aren't justification for API behavior, but the API
reference has always pointed out that these PUT operations are for
*compute* services:
https://developer.openstack.org/api-ref/compute/#compute-services-os-services
This has come up while working on an API microversion [1] where we'll
now expose service uuids in GET calls and take a service uuid in PUT and
DELETE calls to the os-services API. The uuid is needed to uniquely
identify a service across cells. I plan on restricting PUT
/os-services/{service_id} calls to only nova-compute services, and
return a 400 on any other service like nova-conductor or nova-scheduler,
since it doesn't make sense to enable/disable/force-down non-compute
services.
This email is to provide awareness of this change and to also see if
there are any corner cases in which people are relying on any of this
behavior that we don't know about - this is your chance to speak up
before we make the change.
[1]
https://review.openstack.org/#/c/464280/11/nova/api/openstack/compute/services.py@288
--
Thanks,
Matt
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
