Open Stack

Thierry Carrez wrote:
> For the short term, we need some openstack-api client tool released and
> packaged, in particular because it is being used in the zones test, but
> also to start promoting the openstack API.
> 
> * python-cloudservers is not under our control, so not easily extended
> * We have a python-novatools fork currently using "novatools" as the CLI
> tool
> * Sandy proposes
>   * rename "novatools" CLI to "nova"
>   * Add copyright headers and dual BSD/Apache licensing
>   * Push python-novatools in nova itself under nova/clients/python/oscompute
> * Objections from Andy on the need to fork python-cloudservers and the
> perceived non-responsiveness of JKM

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