+10 for lowercase.
On Thu, Feb 24, 2011 at 12:00 PM, Eric Day <e...@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; so...@openstack.org; Rick Clark
> > Cc: Paul Voccio; Matt Dietz; Josh Kearney;
> openstack@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; so...@openstack.org; Rick Clark
> > Cc: Paul Voccio; Matt Dietz; Josh Kearney;
> openstack@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; so...@openstack.org; Rick Clark
> > Cc: Paul Voccio; Matt Dietz; Josh Kearney;
> openstack@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; so...@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@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~openstack
> > More help : https://help.launchpad.net/ListHelp
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
