Thanks John,

While it's nice to have a vision, we also have tactic issues that we need some 
quick movement on.

Can we do something short term to keep all parties happy while continuing this 
larger discussion?


From: John Purrier
Sent: Thursday, February 24, 2011 1:05 PM
To: Sandy Walsh; Andy Smith;; Rick Clark
Cc: Paul Voccio; Matt Dietz; Josh Kearney;
Subject: RE: Novatools ...

Including ttx and the mailing list.

It seems as if the API experience for OpenStack is going to be a hierarchical 
stack, from the lowest level service interfaces to an amalgam/integrated API 
with orchestration. If we are making changes to the bindings and tools does it 
not make sense to get the schema and naming correct out of the gate? I would 

OStools: command line and bindings for the abstracted and orchestrated API. For 
instance, I can request a VM be created with a 100GB volume connected to 
private network “foo” and booted with image ‘bar’.

OScompute: command line and bindings for OpenStack Compute Services (nova).

OSnetwork: command line and bindings for OpenStack Network Services (currently 
in the nova project, but logically distinct).

OSvolume: command line and bindings for OpenStack Volume Services (currently in 
the nova project, but logically distinct).

OSimage: command line and bindings for OpenStack Image Services (glance).

OSobject: command line and bindings for OpenStack Object Store (swift). This 
should be based on the ‘st’ tool currently used.

All services should support an API, a command line tool that drives the API, 
and a web UI (“control panel”) that interfaces with the published API.

Also, we should figure out a consistent schema for service tools (\tools, 
\common, etc.) and make that the standard for all services. The code should be 
part of the normal OpenStack project sources, and be packaged and distributed 
in a consistent manner.

Thierry, do you have suggestions on the copyright headers?



From: Sandy Walsh
Sent: Thursday, February 24, 2011 10:33 AM
To: Andy Smith; John Purrier;; Rick Clark
Cc: Paul Voccio; Matt Dietz; Josh Kearney
Subject: Novatools ...

Hi guys,

We have some issues around novatools that should be addressed.

Here's a little background:

Novatools started as a fork of python-cloudservers 
( created by jacobian. It's a 
nice package; well documented, has tests and provides good cmdline and a client 

However, we needed to make changes for it to work with nova. Those changes were 
made and pull requests were sent to jacobian for inclusion in his branch. They 
were never accepted (nor rejected). In the meanwhile, more work went into our 
cloudservers fork: pause, suspend, diagnostics, zones, etc.

Because more and more people were asking about cmdline tools for nova, we kept 
pointing them to our fork. It was clear that this needed to be put under more 
authoritative control, so we moved it to the rackspace github account.

To avoid conflict with existing cloudserver installs, we rebranded as novatools 
and moved forward.

The reality is we need a place where we can push changes quickly and not be 
hogtied waiting for merge. Without this, we end up pointing the community to 
our local branch anyway. If jacobian wants to regain control of this branch, we 
need assurances of timely responses.

With the zone work in nova we also started using the new novatools as a client 
library to nova, for forwarding requests from one zone to another. This had 
implications on hudson and nova packaging. Hudson requires packages in PPA and 
I had placed it in PyPi. So this causes more issues.

One issue is the BSD license vs. our standard Apache license. From my 
understanding it is possible to change licenses, just not retroactively. We 
aren't proposing to do that.

We also need to change our headers to reflect copyright of Jacobian and 
Rackspace. I'm less sure how to go about that and appease all parties.

Naming. We are going to rename to python-nova with nova being the cmdline tool. 
The tool will not include swift/glance cmdline options. If glance wants to 
inherit from the python-nova infrastructure, that's fine, but it would be a 
separate package.

If there are no objections, I'll get started immediately on the changes.


PS> Andy, do you have a reliable contact for Jacobian? I'd like to hear his 
thoughts, but he's incredibly hard to get a hold of.

Mailing list:
Post to     :
Unsubscribe :
More help   :

Reply via email to