Open Stack

I see the value in having a separate CLI tool per service as:

a. Scales easily, no cross-service dependencies.
b. Expectations are clear that each service must provide an API and CLI to
drive it.
c. Interactions can be clearly targeted to a specified service (no
ambiguity).
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.

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