openstack team mailing list archive

[Eric Day <eday@xxxxxxxxxxxx>]

In regards to openstack tools, we certainly have some options. We
could do everything from one big package with all tools for all
languages/services to one project for each language/service (and all
permutations in between). IMHO, I think it makes the most sense to
keep the client tools for all (or at least a few primary) languages
directly in the service project, so Nova would have clients/python,
clients/ruby, etc. This makes it easier to reuse those packages within
the service (like you need to do for cross-zone communication). Folks
can always start new projects for interfacing with the service
(other languages, more abstractions, ...), but some core tools will be
provided in the main project. Note that this is for the code rep. When
tools are actually packaged up for distribution, they can appear as
different packages (for example, python-nova-tools, python-nova-server,
...) so you don't need to install everything to get just the tools.

I can see great arguments for other layouts too, but in the past I've
found this really helps to keep things in sync.

-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