Open Stack

I like the idea of a single nova entry point, the scope of which
expands to include operations frequently reserved for ops and admins
when you install some extra python code.

It seems structuring this loop around all instances and calling
evacuate (specifying a host, or not, as required) seems like a good
CLI extension, that simply calls into existing python-novaclient CLI
binding, and would look like the exisiting extensions, but without the
API wrapper bits, and just accessing the existing APIs in nova-client:
https://github.com/openstack/python-novaclient/blob/master/novaclient/v1_1/contrib/instance_action.py

John


On 26 April 2013 22:22, Aarti Kriplani <aarti.kriplani at rackspace.com> wrote:
> 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.
>
> Thanks,
> Aarti
> ________________________________________
> 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
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev