openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #00945
Re: Novatools ...
I would encourage using all lowercase for command line tools
(oscompute), I don't really care what the name is though. :)
-Eric
On Thu, Feb 24, 2011 at 05:42:56PM +0000, Sandy Walsh wrote:
> 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.
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
Follow ups
References