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
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
