openstack team mailing list archive

["John Purrier" <john@xxxxxxxxxxxxx>]

Sounds good.

John

-----Original Message-----
From: Eric Day [mailto:eday@xxxxxxxxxxxx] 
Sent: Thursday, February 24, 2011 6:17 PM
To: John Purrier
Cc: 'Devin Carlen'; 'Jay Pipes'; 'Josh Kearney'; soren@xxxxxxxxxxxxx; 'Andy
Smith'; openstack@xxxxxxxxxxxxxxxxxxx; 'Rick Clark'; 'John Purrier'
Subject: Re: [Openstack] Novatools ...

Hi John,

I think the "super tool" should be named openstack, I don't think
anyone was proposing we call that nova. Each individual project can
use whatever name it likes, for example:

nova create instance
glance describe images
openstack create cluster <netowork> <imaage> <count>

The last one would use the nova/glance/network APIs/tools to actually
do the work, it's just a thin wrapper around service specific tools.

-Eric

On Thu, Feb 24, 2011 at 05:49:43PM -0600, John Purrier wrote:
> 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
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp