openstack team mailing list archive

["John Purrier" <john@xxxxxxxxxxxxx>]

I guess I will be the odd man out, but using the project name for compute as
the command line tool name makes no sense. As we add more projects and
services it makes less sense to drive them from a tool called 'nova'. For
example, today swift has a tool called st to manipulate its rest api. Are we
saying that it is logical to run 'nova list container'?

I would prefer to use 'openstack' and then let people alias it to something
shorter.

I do like the idea of having an interactive shell, as well as direct api
calls in the tool.

/nitpick

John

-----Original Message-----
From: openstack-bounces+john=openstack.org@xxxxxxxxxxxxxxxxxxx
[mailto:openstack-bounces+john=openstack.org@xxxxxxxxxxxxxxxxxxx] On Behalf
Of Devin Carlen
Sent: Thursday, February 24, 2011 4:34 PM
To: Jay Pipes
Cc: Josh Kearney; soren@xxxxxxxxxxxxx; Andy Smith;
openstack@xxxxxxxxxxxxxxxxxxx; John Purrier; Rick Clark
Subject: Re: [Openstack] Novatools ...

This is a bit nitpicky but I'd rather see it called just "nova", as in:

nova describe images

Who has strong opinions?

On Feb 24, 2011, at 1:30 PM, Jay Pipes wrote:

> On Thu, Feb 24, 2011 at 4:06 PM, Eric Day <eday@xxxxxxxxxxxx> wrote:
>> On Thu, Feb 24, 2011 at 03:48:25PM -0500, Jay Pipes wrote:
>>> I just don't want to end up with:
>>> 
>>> os-describe-images
>>> os-describe-image-attribute
>>> os-describe-instances
>>> os-describe-groups
>>> os-describe-zones
>>> os-describe-keypairs
>>> os-describe-volumes
>>> os-describe-snapshots
>>> 
>>> The above is asinine, IMO.
>> 
>> Completely agree. :)
> 
> Cool. Was starting to lose my mind thinking people *really* wanted to
> duplicate the eucatools mess...
> 
>>> If you want to have an os-compute and an os-network CLI tool, cool,
>>> but I think that:
>>> 
>>> os-compute describe images
>>> os-compute describe image-attribute
>>> os-compute describe instances
>>> os-compute describe groups
>>> etc...
>>> 
>>> is far more workable than 15 separate CLI tools that do essentially
>>> identical things.
>> 
>> Yup, agree. Also keep in mind that some operations may be duplicates
>> across services, just with a different context. For example,
>> in a deployment where you use glance backed by swift for nova,
>> os-compute describe image <id> may be the same as os-image describe
>> <id> or os-object describe <id> (swift), but the os-compute is in
>> the context of instances so it could have more metadata. This will
>> mirror the dependency tree we see between services (especially as
>> they are split out).
> 
> ++
> 
>> We want to make sure there are tools so services can stand alone as
>> needed (for example, os-image if you run glance standalone). Services
>> that combine other services (like nova) should aggregate these into
>> context-specific commands so you don't *need* to use the underlying
>> service tools for most things. This allows you to control nova use
>> one tool. :)
> 
> No disagreement from me.
> 
> -jay
> 
> p.s. thx for not sending me to /dev/null ;)
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp


_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp