Open Stack

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