openstack team mailing list archive

[Eric Day <eday@xxxxxxxxxxxx>]

For copyright headers, just add a new "Copyright 2011 OpenStack,
LLC." line for existing files under the old copyright line. You can add
a new license for new code for existing files, but that gets messy. For
new files, just do as we usually do for new files (copyright + license
brief). You can also add new files under a different license (Apache
instead of BSD) if you like, but I'd probably keep it the same within
one project for simplicity. Note that this is only suitable since
it's BSD, if it were GPL (or some other viral license), it would be
a bit different.

-Eric

On Thu, Feb 24, 2011 at 05:27:55PM +0000, Sandy Walsh wrote:
>    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