+10 for lowercase.<br><br><div class="gmail_quote">On Thu, Feb 24, 2011 at 12:00 PM, Eric Day <span dir="ltr"><<a href="mailto:eday@oddments.org">eday@oddments.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I would encourage using all lowercase for command line tools<br>
(oscompute), I don't really care what the name is though. :)<br>
<font color="#888888"><br>
-Eric<br>
</font><div><div></div><div class="h5"><br>
On Thu, Feb 24, 2011 at 05:42:56PM +0000, Sandy Walsh wrote:<br>
>    Perfect.<br>
>    Objections? (naming bun-fights discouraged ;)<br>
>    -S<br>
><br>
>      ----------------------------------------------------------------------<br>
><br>
>    From: John Purrier<br>
>    Sent: Thursday, February 24, 2011 1:39 PM<br>
>    To: Sandy Walsh; Andy Smith; <a href="mailto:soren@openstack.org">soren@openstack.org</a>; Rick Clark<br>
>    Cc: Paul Voccio; Matt Dietz; Josh Kearney; <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
>    Subject: RE: Novatools ...<br>
><br>
>    Sure, here are the tactical issues you identify (correct me if I miss<br>
>    any):<br>
><br>
><br>
><br>
>    1.       We have essentially forked python-cloudservers. As you point out,<br>
>    we should make a best effort to get our changes back into the original<br>
>    project.<br>
><br>
>    2.       We should integrate the command line and bindings into the nova<br>
>    project on LP. This should serve as the template for other services.<br>
><br>
>    3.       We should name the tool OScompute.<br>
><br>
>    4.       We should use PPA packaging for Hudson compatibility.<br>
><br>
>    5.       Thierry (and others with knowledge) will weigh in on the<br>
>    copyright headers issue. We can get RackLaw involved if necessary.<br>
><br>
><br>
><br>
>    This is consistent with an overall direction and allows specific changes<br>
>    to be made today.<br>
><br>
><br>
><br>
>    Thoughts?<br>
><br>
><br>
><br>
>    John<br>
><br>
><br>
><br>
>    From: Sandy Walsh<br>
>    Sent: Thursday, February 24, 2011 11:28 AM<br>
>    To: John Purrier; Andy Smith; <a href="mailto:soren@openstack.org">soren@openstack.org</a>; Rick Clark<br>
>    Cc: Paul Voccio; Matt Dietz; Josh Kearney; <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
>    Subject: RE: Novatools ...<br>
><br>
><br>
><br>
>    Thanks John,<br>
><br>
><br>
><br>
>    While it's nice to have a vision, we also have tactic issues that we need<br>
>    some quick movement on.<br>
><br>
><br>
><br>
>    Can we do something short term to keep all parties happy while continuing<br>
>    this larger discussion?<br>
><br>
><br>
><br>
>    -S<br>
><br>
><br>
><br>
>    --------------------------------------------------------------------------<br>
><br>
>    From: John Purrier<br>
>    Sent: Thursday, February 24, 2011 1:05 PM<br>
>    To: Sandy Walsh; Andy Smith; <a href="mailto:soren@openstack.org">soren@openstack.org</a>; Rick Clark<br>
>    Cc: Paul Voccio; Matt Dietz; Josh Kearney; <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
>    Subject: RE: Novatools ...<br>
><br>
>    Including ttx and the mailing list.<br>
><br>
><br>
><br>
>    It seems as if the API experience for OpenStack is going to be a<br>
>    hierarchical stack, from the lowest level service interfaces to an<br>
>    amalgam/integrated API with orchestration. If we are making changes to the<br>
>    bindings and tools does it not make sense to get the schema and naming<br>
>    correct out of the gate? I would suggest:<br>
><br>
><br>
><br>
>    OStools: command line and bindings for the abstracted and orchestrated<br>
>    API. For instance, I can request a VM be created with a 100GB volume<br>
>    connected to private network "foo" and booted with image `bar'.<br>
><br>
><br>
><br>
>    OScompute: command line and bindings for OpenStack Compute Services<br>
>    (nova).<br>
><br>
><br>
><br>
>    OSnetwork: command line and bindings for OpenStack Network Services<br>
>    (currently in the nova project, but logically distinct).<br>
><br>
><br>
><br>
>    OSvolume: command line and bindings for OpenStack Volume Services<br>
>    (currently in the nova project, but logically distinct).<br>
><br>
><br>
><br>
>    OSimage: command line and bindings for OpenStack Image Services (glance).<br>
><br>
><br>
><br>
>    OSobject: command line and bindings for OpenStack Object Store (swift).<br>
>    This should be based on the `st' tool currently used.<br>
><br>
><br>
><br>
>    All services should support an API, a command line tool that drives the<br>
>    API, and a web UI ("control panel") that interfaces with the published<br>
>    API.<br>
><br>
><br>
><br>
>    Also, we should figure out a consistent schema for service tools (\tools,<br>
>    \common, etc.) and make that the standard for all services. The code<br>
>    should be part of the normal OpenStack project sources, and be packaged<br>
>    and distributed in a consistent manner.<br>
><br>
><br>
><br>
>    Thierry, do you have suggestions on the copyright headers?<br>
><br>
><br>
><br>
>    Thanks,<br>
><br>
><br>
><br>
>    John<br>
><br>
><br>
><br>
>    From: Sandy Walsh<br>
>    Sent: Thursday, February 24, 2011 10:33 AM<br>
>    To: Andy Smith; John Purrier; <a href="mailto:soren@openstack.org">soren@openstack.org</a>; Rick Clark<br>
>    Cc: Paul Voccio; Matt Dietz; Josh Kearney<br>
>    Subject: Novatools ...<br>
><br>
><br>
><br>
>    Hi guys,<br>
><br>
><br>
><br>
>    We have some issues around novatools that should be addressed.<br>
><br>
><br>
><br>
>    Here's a little background:<br>
><br>
><br>
><br>
>    Novatools started as a fork of python-cloudservers<br>
>    (<a href="https://github.com/jacobian/python-cloudservers" target="_blank">https://github.com/jacobian/python-cloudservers</a>) created by jacobian.<br>
>    It's a nice package; well documented, has tests and provides good cmdline<br>
>    and a client library.<br>
><br>
><br>
><br>
>    However, we needed to make changes for it to work with nova. Those changes<br>
>    were made and pull requests were sent to jacobian for inclusion in his<br>
>    branch. They were never accepted (nor rejected). In the meanwhile, more<br>
>    work went into our cloudservers fork: pause, suspend, diagnostics, zones,<br>
>    etc.<br>
><br>
><br>
><br>
>    Because more and more people were asking about cmdline tools for nova, we<br>
>    kept pointing them to our fork. It was clear that this needed to be put<br>
>    under more authoritative control, so we moved it to the rackspace github<br>
>    account.<br>
><br>
><br>
><br>
>    To avoid conflict with existing cloudserver installs, we rebranded as<br>
>    novatools and moved forward.<br>
><br>
><br>
><br>
>    The reality is we need a place where we can push changes quickly and not<br>
>    be hogtied waiting for merge. Without this, we end up pointing the<br>
>    community to our local branch anyway. If jacobian wants to regain control<br>
>    of this branch, we need assurances of timely responses.<br>
><br>
><br>
><br>
>    With the zone work in nova we also started using the new novatools as a<br>
>    client library to nova, for forwarding requests from one zone to another.<br>
>    This had implications on hudson and nova packaging. Hudson requires<br>
>    packages in PPA and I had placed it in PyPi. So this causes more issues.<br>
><br>
><br>
><br>
>    One issue is the BSD license vs. our standard Apache license. From my<br>
>    understanding it is possible to change licenses, just not retroactively.<br>
>    We aren't proposing to do that.<br>
><br>
><br>
><br>
>    We also need to change our headers to reflect copyright of Jacobian and<br>
>    Rackspace. I'm less sure how to go about that and appease all parties.<br>
><br>
><br>
><br>
>    Naming. We are going to rename to python-nova with nova being the cmdline<br>
>    tool. The tool will not include swift/glance cmdline options. If glance<br>
>    wants to inherit from the python-nova infrastructure, that's fine, but it<br>
>    would be a separate package.<br>
><br>
><br>
><br>
>    If there are no objections, I'll get started immediately on the changes.<br>
><br>
><br>
><br>
>    Thanks,<br>
><br>
>    Sandy<br>
><br>
><br>
><br>
>    PS> Andy, do you have a reliable contact for Jacobian? I'd like to hear<br>
>    his thoughts, but he's incredibly hard to get a hold of.<br>
><br>
><br>
><br>
><br>
<br>
</div></div><div><div></div><div class="h5">> _______________________________________________<br>
> Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
> Post to     : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
> Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
> More help   : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
<br>
<br>
_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to     : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help   : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
</div></div></blockquote></div><br>