[nova] Does anyone rely on PUT /os-services/disable for non-compute services?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[nova] Does anyone rely on PUT /os-services/disable for non-compute services?

Matt Riedemann-3
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 Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [nova] Does anyone rely on PUT /os-services/disable for non-compute services?

Matt Riedemann-3
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 Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [nova] Does anyone rely on PUT /os-services/disable for non-compute services?

Dan Smith-2
> 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.

Please, #2. Please.

--Dan

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Openstack-operators] [nova] Does anyone rely on PUT /os-services/disable for non-compute services?

Matt Riedemann-3
On 6/13/2017 8:17 PM, Dan Smith wrote:

>> 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.
>
> Please, #2. Please.
>
> --Dan
>
> _______________________________________________
> OpenStack-operators mailing list
> [hidden email]
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Are we allowed to cheat and say auto-disabling non-nova-compute services
on startup is a bug and just fix it that way for #2? :) Because (1) it
doesn't make sense, as far as we know, and (2) it forces the operator to
have to use the API to enable them later just to fix their nova
service-list output.

--

Thanks,

Matt

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Openstack-operators] [nova] Does anyone rely on PUT /os-services/disable for non-compute services?

Dan Smith-2
> Are we allowed to cheat and say auto-disabling non-nova-compute services
> on startup is a bug and just fix it that way for #2? :) Because (1) it
> doesn't make sense, as far as we know, and (2) it forces the operator to
> have to use the API to enable them later just to fix their nova
> service-list output.

Yes, definitely.

--Dan

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Openstack-operators] [nova] Does anyone rely on PUT /os-services/disable for non-compute services?

Kris G. Lindgren
I am fine with #2, and I am also fine with calling it a bug.  Since the enabled/disabled state for the other services didn’t actually do anything.


___________________________________________________________________
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy

On 6/13/17, 8:46 PM, "Dan Smith" <[hidden email]> wrote:

    > Are we allowed to cheat and say auto-disabling non-nova-compute services
    > on startup is a bug and just fix it that way for #2? :) Because (1) it
    > doesn't make sense, as far as we know, and (2) it forces the operator to
    > have to use the API to enable them later just to fix their nova
    > service-list output.
   
    Yes, definitely.
   
    --Dan
   
    _______________________________________________
    OpenStack-operators mailing list
    [hidden email]
    http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
   

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Loading...