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 <j...@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....@lists.launchpad.net > > [mailto:openstack-bounces+john=openstack....@lists.launchpad.net] On Behalf > > Of Jay Pipes > > Sent: Thursday, February 24, 2011 12:20 PM > > To: Eric Day > > Cc: Josh Kearney; so...@openstack.org; Andy Smith; > > openstack@lists.launchpad.net; John Purrier; Rick Clark > > Subject: Re: [Openstack] Novatools ... > > > > On Thu, Feb 24, 2011 at 1: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. :) > > > > 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@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