Open Stack

On 6/13/2017 12:19 PM, Matt Riedemann wrote:
> 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 
> 
> 

Kris Lindgren brought up a good point in IRC today about this.

If you configure enable_new_services=False, when new services are 
created they will be automatically disabled [1].

As noted earlier, disabled nova-conductor, nova-scheduler, etc, doesn't 
really mean anything. However, if we don't allow you to enable them via 
the API (the new PUT /os-services/{service_uuid} microversion), then 
those are going to be listed as disabled until you tweak them in the 
database directly, which isn't good.

And trying to get around this by using "PUT /os-services/enable" with 
microversion 2.1 won't work in Pike because of the host mapping issue I 
mentioned before.

So it seems our options are:

1. Allow PUT /os-services/{service_uuid} on any type of service, even if 
doesn't make sense for non-nova-compute services.

2. Change the behavior of [1] to only disable new "nova-compute" services.

[1] 
https://github.com/openstack/nova/blob/d26b3e7051a89160ad26c38548fcf0c08c06dc33/nova/db/sqlalchemy/api.py#L588

-- 

Thanks,

Matt