openstack team mailing list archive

[Sandy Walsh <sandy.walsh@xxxxxxxxxxxxx>]

Thanks Thierry for summarizing the concerns.

I have a new version in https://github.com/rackspace/python-novatools

This does the following:
1. Renames the cmdline tool to nova. The package is still python-novatools
2. Ups the version # to 2.1
3. Changes the license to Apache for 2.1+. Prior versions are still BSD
4. Adds Openstack & Apache copyright notices to all source files.
5. Better exception reporting (real functionality!)

I have not moved the code into nova since, with these changes, getting it into the PPA should be less arduous.

If anyone has any concerns with this plan, please comment in this thread or attend the openstack meeting tomorrow. I've added it to the agenda: http://wiki.openstack.org/Meetings

Thanks again and sorry for raising the dead :)

-Sandy


On Fri, Feb 25, 2011 at 3:20 AM, Thierry Carrez <thierry@xxxxxxxxxxxxx<mailto:thierry@xxxxxxxxxxxxx>> wrote:
Thierry Carrez wrote:

That's three separate issues. (1) do we need a fork, (2) last changes to
python-novatools before making them packageable (rename tool and file
header fixes), and (3) make it part of lp:nova or not (and where)

On (1) I think we need to be able to control the code, which leaves two
options: (1a) JKM gives ownership to us, renames package to something
more less cloudservers-branded or (1b) Let python-cloudservers live and
fork our own nova-branded tool. Since (1b) is kinda already done and
given our time contraints, I tend to lean in (1b) direction.

(2) must be done in all cases since that's a bit of prerequisite for
proper packaging.

On (2)/(3) I think we should rename the tool to "nova" and move the
python-novatools code in nova codebase *only if* it can be reused in the
long-term plan: if we plan to drop it and replace the "nova" CLI tool by
something completely different that does not support the same commands,
then I think it should rather live outside the nova source tree. Do we
think the current tool can be reused as-is in the long-term plan ?

Also note that (3) creates a contraint of keeping the client code up to
date with the rest of nova and prevents it to change after a release,
but maybe that's a good thing :)

--
Thierry Carrez (ttx)
Release Manager, OpenStack



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@xxxxxxxxxxxxx, and delete the original message. 
Your cooperation is appreciated.