Open Stack

On 11/18/2015 8:58 AM, Andy Hill wrote:
> Hi Matt,
>
> Why were we deprecating service management with nova-manage? Just to
> remove duplication?
>
> I actually like having two paths- if there is an issue with the service
> API being able to use nova-manage as a fail-safe doesn't stop me from
> adding new capacity. The availability of the services API and capacity
> availability are two very different worlds. :)
>
> -AH
>
>
> On Fri, Nov 13, 2015 at 10:49 AM, Matt Riedemann
> <mriedem at linux.vnet.ibm.com <mailto:mriedem at linux.vnet.ibm.com>> wrote:
>
>     This is an FYI *before* the change is merged, for a change. :)
>
>     https://review.openstack.org/#/c/240858/
>
>     This just deprecates the nova-manage service commands in favor of
>     using python-novaclient. To be removed in the 14.0 'N' release.
>
>     The only difference is nova-manage will hit the database directly
>     whereas novaclient has to go through the REST API.
>
>     If you have objections to this for whatever reason, please speak up
>     here or in the review.
>
>     --
>
>     Thanks,
>
>     Matt Riedemann
>
>
>     _______________________________________________
>     OpenStack-operators mailing list
>     OpenStack-operators at lists.openstack.org
>     <mailto:OpenStack-operators at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>

Well that was the question I posed in the blueprint and the change 
before it was approved, and that's historically been the only reason 
we've left commands in nova-manage (besides things that we don't have 
alternative CLI for, like the db sub-commands). And that's why I bring 
it up here for awareness, albeit after the change is merged.

If you have a strong use case for why this is needed, i.e. nova-api is 
down everywhere and you need to get to the services records in the 
database via CLI, then please post that here or add it as an agenda item 
to the next nova meeting (under open discussion). No one on the review 
could come up with a reasonable use case to justify not deprecating the 
command.

-- 

Thanks,

Matt Riedemann