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

Alex Glikson GLIKSON at il.ibm.com
Mon Apr 29 20:44:27 UTC 2013


+1

Alex

John Garbutt <john at johngarbutt.com> wrote on 29/04/2013 09:10:28 PM:

> From: John Garbutt <john at johngarbutt.com>
> To: OpenStack Development Mailing List 
<openstack-dev at lists.openstack.org>, 
> Date: 29/04/2013 09:23 PM
> Subject: Re: [openstack-dev] [Nova] Future of nova-api operations 
> that act on all servers on a host
> 
> 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
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130429/7de5ec34/attachment.html>


More information about the OpenStack-dev mailing list