I agree with Mr. Pipes. I’ve not used that API ever and I’ve no recollection of
anyone asking about it nor am I aware of anyone who actually uses it. I vote to
deprecate.
-----Original Message-----
From: Jay Pipes <jaypi...@gmail.com>
Date: Saturday, April 1, 2017 at 10:02 AM
To: "openstack-operators@lists.openstack.org"
<openstack-operators@lists.openstack.org>
Subject: Re: [Openstack-operators] [nova] Can we deprecate the os-hosts API?
My vote is to deprecate it.
On 03/22/2017 11:16 AM, Matt Riedemann wrote:
> This is mostly directed at operators but I'm cross-posting to the ops
> and dev lists.
>
> First, does anyone use the os-hosts API and if so, for what use cases?
>
> The os-hosts and os-services APIs are very similar, and they work on the
> same resources (the 'services' records in the nova database).
>
> Both APIs allow you to list services and show details for a specific
> service.
>
> Both APIs allow you to enable and disable a service so instances will
> not be scheduled to that service (compute host).
>
> There are some additional 'action' APIs that are specific to the
> os-hosts API, which are:
>
> 1. Putting the service (host) into maintenance mode. This is only
> implemented by the XenServer virt driver and despite the description in
> the support matrix [1] I'm told that it doesn't actually evacuate all of
> the guests from the host, it just sets a flag in the Xen management
> console, and is therefore pretty useless. Regardless, we have other APIs
> that allow you to do the same thing which are supported across all virt
> drivers, which would be disabling a service and then migrating the
> instances off that host.
>
> 2. Reboot host. This is only supported by the XenServer and Hyper-v
> drivers. This is also arguably something that does not need to live in
> the compute API. As far as I know, the backing drivers do no
> orchestration of dealing with guests in the nova database when
> performing a reboot of the host. The compute service for that host may
> be temporarily disabled by the service group health check which would
> take it out of scheduling decisions, and the guests would be down, but
> the periodic task which checks for unexpectedly stopped instances runs
> in the nova-compute service, which might be dead now so the nova API
> would show the instances as running when in fact they are actually
stopped.
>
> 3. Shutdown host. Same as #2 for reboot host.
>
> 4. Start host. This is literally not supported by any in-tree virt
> drivers. The only drivers that implement the 'host_power_action' method
> are XenServer and Hyper-v and they do not support the 'startup' action.
> Since this is an RPC call from nova-api to nova-compute, you will at
> least get a 501 error response indicating it is not supported or
> implemented (even though 501 is the wrong response for something like
> this).
>
> --
>
> So is anyone using any of these APIs? As noted, only Xen users can use
> the maintenance mode API but I'm told it's useless. Which leaves the
> stop/reboot power action APIs, which are only for XenServer and Hyper-v.
> Are there any users of those drivers that use those APIs and if so, why?
>
> If no one uses any of those power action or maintenance APIs, then we
> propose to deprecate the os-hosts API. The list/show/enable/disable APIs
> are already covered by the os-services API which we actually intend to
> improve [2] so those would be the replacement.
>
> [1]
>
https://docs.openstack.org/developer/nova/support-matrix.html#operation_maintenance_mode
>
> [2] https://review.openstack.org/#/c/447149/
>
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
