← Back to team overview

openstack team mailing list archive

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