<font size=2 face="sans-serif">+1</font>
<br>
<br><font size=2 face="sans-serif">Alex</font>
<br>
<br><tt><font size=2>John Garbutt <john@johngarbutt.com> wrote on
29/04/2013 09:10:28 PM:<br>
<br>
> From: John Garbutt <john@johngarbutt.com></font></tt>
<br><tt><font size=2>> To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org>,
</font></tt>
<br><tt><font size=2>> Date: 29/04/2013 09:23 PM</font></tt>
<br><tt><font size=2>> Subject: Re: [openstack-dev] [Nova] Future of
nova-api operations <br>
> that act on all servers on a host</font></tt>
<br><tt><font size=2>> <br>
> I like the idea of a single nova entry point, the scope of which<br>
> expands to include operations frequently reserved for ops and admins<br>
> when you install some extra python code.<br>
> <br>
> It seems structuring this loop around all instances and calling<br>
> evacuate (specifying a host, or not, as required) seems like a good<br>
> CLI extension, that simply calls into existing python-novaclient CLI<br>
> binding, and would look like the exisiting extensions, but without
the<br>
> API wrapper bits, and just accessing the existing APIs in nova-client:<br>
> </font></tt><a href="https://github.com/openstack/python-novaclient/blob/master/"><tt><font size=2>https://github.com/openstack/python-novaclient/blob/master/</font></tt></a><tt><font size=2><br>
> novaclient/v1_1/contrib/instance_action.py<br>
> <br>
> John<br>
> <br>
> <br>
> On 26 April 2013 22:22, Aarti Kriplani <aarti.kriplani@rackspace.com>
wrote:<br>
> > Python-novaclient is itself a wrapper around the nova api, adding
<br>
> another CLI tool would again be another wrapper on top of python-<br>
> novaclient. Like John mentioned, we could have it as extensions for
<br>
> admins only. Also, we could work on adding logic to display options
<br>
> based on the user role and not all options, so as to not confuse the<br>
> normal user with the additional commands that he cannot really use.<br>
> > I'm planning to re-write the whole "evacuate host"
extension(<br>
> </font></tt><a href=https://review.openstack.org/#/c/25259/><tt><font size=2>https://review.openstack.org/#/c/25259/</font></tt></a><tt><font size=2>)
in the python-novaclient. <br>
> Would love to get some suggestions.<br>
> ><br>
> > Thanks,<br>
> > Aarti<br>
> > ________________________________________<br>
> > From: Kevin L. Mitchell [kevin.mitchell@rackspace.com]<br>
> > Sent: Tuesday, April 23, 2013 11:46 AM<br>
> > To: openstack-dev@lists.openstack.org<br>
> > Subject: Re: [openstack-dev] [Nova] Future of nova-api operations
<br>
> that act on all servers on a host<br>
> ><br>
> > On Mon, 2013-04-22 at 14:31 -0500, John Garbutt wrote:<br>
> >> I am not sure I like diverging from python-novaclient, I
was thinking<br>
> >> more of a external repo that is full of these style commands:<br>
> >> </font></tt><a href="https://github.com/openstack/python-novaclient/tree/master/"><tt><font size=2>https://github.com/openstack/python-novaclient/tree/master/</font></tt></a><tt><font size=2><br>
> novaclient/v1_1/contrib<br>
> ><br>
> > Who said anything about diverging from python-novaclient?  To
me,<br>
> > "diverging" implies having two independent but complete
implementations<br>
> > of something, and those two implementations start evolving in
different<br>
> > directions.  My proposal is simply set up a new CLI tool
that leverages<br>
> > the python-novaclient API to implement these complex administrative<br>
> > operations.  (And you could, if you wanted to, make those
into CLI<br>
> > extensions to the existing python-novaclient, instead of a separate<br>
> > tool, but I think it becomes cleaner and clearer to use a new<br>
> > "nova-admin" command for that…)<br>
> ><br>
> >> So if you are an admin / ops / support, you install an extra
set of<br>
> >> things, an a whole bunch of extra params light up. Those
commands<br>
> >> should then just call into novaclient to make any API calls
(hmm,<br>
> >> maybe thats a dependency loop).<br>
> > --<br>
> > Kevin L. Mitchell <kevin.mitchell@rackspace.com><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > OpenStack-dev@lists.openstack.org<br>
> > </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
> ><br>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > OpenStack-dev@lists.openstack.org<br>
> > </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
> <br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> OpenStack-dev@lists.openstack.org<br>
> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
> <br>
</font></tt>