[openstack-dev] [Nova] Future of nova-api operations that act on all servers on a host

Aarti Kriplani aarti.kriplani at RACKSPACE.COM
Fri Apr 26 21:22:54 UTC 2013

Python-novaclient is itself a wrapper around the nova api, adding another CLI tool would again be another wrapper on top of python-novaclient. Like John mentioned, we could have it as extensions for admins only. Also, we could work on adding logic to display options based on the user role and not all options, so as to not confuse the normal user with the additional commands that he cannot really use.
I'm planning to re-write the whole "evacuate host" extension(https://review.openstack.org/#/c/25259/) in the python-novaclient. Would love to get some suggestions.

From: Kevin L. Mitchell [kevin.mitchell at rackspace.com]
Sent: Tuesday, April 23, 2013 11:46 AM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [Nova] Future of nova-api operations that act on all servers on a host

On Mon, 2013-04-22 at 14:31 -0500, John Garbutt wrote:
> I am not sure I like diverging from python-novaclient, I was thinking
> more of a external repo that is full of these style commands:
> https://github.com/openstack/python-novaclient/tree/master/novaclient/v1_1/contrib

Who said anything about diverging from python-novaclient?  To me,
"diverging" implies having two independent but complete implementations
of something, and those two implementations start evolving in different
directions.  My proposal is simply set up a new CLI tool that leverages
the python-novaclient API to implement these complex administrative
operations.  (And you could, if you wanted to, make those into CLI
extensions to the existing python-novaclient, instead of a separate
tool, but I think it becomes cleaner and clearer to use a new
"nova-admin" command for that…)

> So if you are an admin / ops / support, you install an extra set of
> things, an a whole bunch of extra params light up. Those commands
> should then just call into novaclient to make any API calls (hmm,
> maybe thats a dependency loop).
Kevin L. Mitchell <kevin.mitchell at rackspace.com>

OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org

More information about the OpenStack-dev mailing list