+1 for long term plan discussion at the summit<div>+1 for having this in the diablo release<br><div>+1 for short term goal: tool being under our control via fork I don't think JKM will keep up (nothing against JKM, it's just a lot of work).<br>
<br><div class="gmail_quote">On Fri, Feb 25, 2011 at 3:20 AM, Thierry Carrez <span dir="ltr"><<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">Thierry Carrez wrote:<br>
> For the short term, we need some openstack-api client tool released and<br>
> packaged, in particular because it is being used in the zones test, but<br>
> also to start promoting the openstack API.<br>
><br>
> * python-cloudservers is not under our control, so not easily extended<br>
> * We have a python-novatools fork currently using "novatools" as the CLI<br>
> tool<br>
> * Sandy proposes<br>
>   * rename "novatools" CLI to "nova"<br>
>   * Add copyright headers and dual BSD/Apache licensing<br>
>   * Push python-novatools in nova itself under nova/clients/python/oscompute<br>
> * Objections from Andy on the need to fork python-cloudservers and the<br>
> perceived non-responsiveness of JKM<br>
<br>
</div>That's three separate issues. (1) do we need a fork, (2) last changes to<br>
python-novatools before making them packageable (rename tool and file<br>
header fixes), and (3) make it part of lp:nova or not (and where)<br>
<br>
On (1) I think we need to be able to control the code, which leaves two<br>
options: (1a) JKM gives ownership to us, renames package to something<br>
more less cloudservers-branded or (1b) Let python-cloudservers live and<br>
fork our own nova-branded tool. Since (1b) is kinda already done and<br>
given our time contraints, I tend to lean in (1b) direction.<br>
<br>
(2) must be done in all cases since that's a bit of prerequisite for<br>
proper packaging.<br>
<br>
On (2)/(3) I think we should rename the tool to "nova" and move the<br>
python-novatools code in nova codebase *only if* it can be reused in the<br>
long-term plan: if we plan to drop it and replace the "nova" CLI tool by<br>
something completely different that does not support the same commands,<br>
then I think it should rather live outside the nova source tree. Do we<br>
think the current tool can be reused as-is in the long-term plan ?<br>
<br>
Also note that (3) creates a contraint of keeping the client code up to<br>
date with the rest of nova and prevents it to change after a release,<br>
but maybe that's a good thing :)<br>
<div><div></div><div class="h5"><br>
--<br>
Thierry Carrez (ttx)<br>
Release Manager, OpenStack<br>
<br>
_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to     : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help   : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
</div></div></blockquote></div><br></div></div><PRE>
Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is prohibited.
If you receive this transmission in error, please notify us immediately by e-mail
at abuse@rackspace.com, and delete the original message.
Your cooperation is appreciated.
</PRE>