openstack team mailing list archive

[Sandy Walsh <sandy.walsh@xxxxxxxxxxxxx>]

Perfect.

Objections? (naming bun-fights discouraged ;)

-S
________________________________
From: John Purrier
Sent: Thursday, February 24, 2011 1:39 PM
To: Sandy Walsh; Andy Smith; soren@xxxxxxxxxxxxx; Rick Clark
Cc: Paul Voccio; Matt Dietz; Josh Kearney; openstack@xxxxxxxxxxxxxxxxxxx
Subject: RE: Novatools ...

Sure, here are the tactical issues you identify (correct me if I miss any):


1.       We have essentially forked python-cloudservers. As you point out, we should make a best effort to get our changes back into the original project.

2.       We should integrate the command line and bindings into the nova project on LP. This should serve as the template for other services.

3.       We should name the tool OScompute.

4.       We should use PPA packaging for Hudson compatibility.

5.       Thierry (and others with knowledge) will weigh in on the copyright headers issue. We can get RackLaw involved if necessary.

This is consistent with an overall direction and allows specific changes to be made today.

Thoughts?

John

From: Sandy Walsh
Sent: Thursday, February 24, 2011 11:28 AM
To: John Purrier; Andy Smith; soren@xxxxxxxxxxxxx; Rick Clark
Cc: Paul Voccio; Matt Dietz; Josh Kearney; openstack@xxxxxxxxxxxxxxxxxxx
Subject: RE: Novatools ...

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?

-S

________________________________
From: John Purrier
Sent: Thursday, February 24, 2011 1:05 PM
To: Sandy Walsh; Andy Smith; soren@xxxxxxxxxxxxx; Rick Clark
Cc: Paul Voccio; Matt Dietz; Josh Kearney; openstack@xxxxxxxxxxxxxxxxxxx
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 suggest:

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?

Thanks,

John

From: Sandy Walsh
Sent: Thursday, February 24, 2011 10:33 AM
To: Andy Smith; John Purrier; soren@xxxxxxxxxxxxx; 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 (https://github.com/jacobian/python-cloudservers) created by jacobian. It's a nice package; well documented, has tests and provides good cmdline and a client library.

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.

Thanks,
Sandy

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.