Open Stack

Perhaps I'm missing something, but I'm not sure what you mean by
"one API". Each project/service will be driving their own API,
no? For example do you expect one CLI tool for swift, nova, and a
queue service?

I see John's points with allowing each service to drive their own
API/tools (hopefully following some cross-project guidelines so they
are consistent), and then possibly supplying a "super tool" that allows
complex orchestration using the other tools when needed. For example:

os-super-tool create cluster <network> <nodes> <images> ...

This would in turn use os-compute, os-network, etc.

We could also do some tool reflection to allow:

os-compute <args>

To be the same as:

 os-super-tool compute <args>

So you can only use os-super-tool if you don't want to remember all
the others.

-Eric

On Thu, Feb 24, 2011 at 02:27:58PM -0500, Jay Pipes wrote:
> On Thu, Feb 24, 2011 at 2:19 PM, John Purrier <john at openstack.org> wrote:
> > I see the value in having a separate CLI tool per service as:
> >
> > a. Scales easily, no cross-service dependencies.
> 
> I'm talking about CLI tools that access the API, not the individual services...
> 
> > b. Expectations are clear that each service must provide an API and CLI to
> > drive it.
> 
> No, there is only one OpenStack API. A single tool to talk this API is
> what I'm recommending....
> 
> > c. Interactions can be clearly targeted to a specified service (no
> > ambiguity).
> 
> Again, only one API...
> 
> > d. These tools are naturally built by the developers to debug the service as
> > it is being built.
> >
> > As I mentioned, we can (should?) also have an aggregated "ostools" framework
> > that can drive any of the lower level tools, as well as invoke any higher
> > level orchestration constructs that we build.
> >
> > This makes sense to me, but at the end of the day we need a toolset that can
> > drive our service interfaces. Singular or a collection of tools is less
> > important than the fact that the service API's exist and can be accessed via
> > scripts and the command line.
> 
> Sorry, I don't see how having a proliferations of little command-line
> tools for managing OpenStack services is useful. Managing OpenStack
> services should be done through the OpenStack API, not via multiple
> little tools...
> 
> Just my 2 cents,
> jay
> 
> > John
> >
> > -----Original Message-----
> > From: openstack-bounces+john=openstack.org at lists.launchpad.net
> > [mailto:openstack-bounces+john=openstack.org at lists.launchpad.net] On Behalf
> > Of Jay Pipes
> > Sent: Thursday, February 24, 2011 12:20 PM
> > To: Eric Day
> > Cc: Josh Kearney; soren at openstack.org; Andy Smith;
> > openstack at lists.launchpad.net; John Purrier; Rick Clark
> > Subject: Re: [Openstack] Novatools ...
> >
> > On Thu, Feb 24, 2011 at 1: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. :)
> >
> > Why is there a need for more than 1 CLI tool? What is the point? I
> > find the euca-* separate tools to be a complete and utter disaster.
> > Having fewer CLI tools makes more sense to me than having eleventy
> > billion mostly-similar CLI tools.
> >
> > -jay
> >
> > _______________________________________________
> > 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
> >
> >