Open Stack

+10 for lowercase.

On Thu, Feb 24, 2011 at 12:00 PM, Eric Day <eday at oddments.org> wrote:

> 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 at openstack.org; Rick Clark
> >    Cc: Paul Voccio; Matt Dietz; Josh Kearney;
> openstack at lists.launchpad.net
> >    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 at openstack.org; Rick Clark
> >    Cc: Paul Voccio; Matt Dietz; Josh Kearney;
> openstack at lists.launchpad.net
> >    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 at openstack.org; Rick Clark
> >    Cc: Paul Voccio; Matt Dietz; Josh Kearney;
> openstack at lists.launchpad.net
> >    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 at openstack.org; 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 at lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~openstack
> > More help   : https://help.launchpad.net/ListHelp
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110224/51ae84b1/attachment.html>