openstack team mailing list archive

[Ewan Mellor <Ewan.Mellor@xxxxxxxxxxxxx>]

> -----Original Message-----
> From: openstack-bounces+ewan.mellor=citrix.com@xxxxxxxxxxxxxxxxxxx
> [mailto:openstack-bounces+ewan.mellor=citrix.com@xxxxxxxxxxxxxxxxxxx]
> On Behalf Of Todd Willey
> Sent: 24 February 2011 17:04
> To: John Purrier
> Cc: Josh Kearney; soren@xxxxxxxxxxxxx; Andy Smith;
> openstack@xxxxxxxxxxxxxxxxxxx; Rick Clark; John Purrier
> Subject: Re: [Openstack] Novatools ...
> 
> I'd like to go on record as saying that anything related to nova or
> openstack that doesn't allow you to configure which public API you're
> consuming shouldn't bear the name nova or openstack.  If you look at
> http://nova.openstack.org/ you see "API Compatibility" in bold as one
> of our design guidelines.  This agnosticism should apply to clients as
> well.
> 
> If I use something called 'nova' or 'openstack', I expect it to run
> against my installation regardless of my particular configuration is.
> It is now (with paste.deploy) trivial to run one API (ec2) and not the
> other (cloudservers).  If we're writing a tool that only uses the
> cloudservers api, it clearly doesn't run against any openstack
> installation, so shouldn't have the names nova or openstack associated
> with it.
> 
> I'm glad novatools exists and we're getting a library that consumes
> one of our APIs, but lets not call it 'nova' or 'os'.  We could in
> fact just keep calling it 'cloudservers' as that is the API it
> exercises.

I disagree.  The API that it exercises is called "The OpenStack API".  It is important that we have a clear future direction with one brand, at CLI and API level.  

The EC2 API is for compatibility only, and the CLI that drives it is called eucatools (et al, no doubt).  Let's leave that mess behind, and have one single OpenStack CLI and API and be proud of it.

Ewan.


> 
> -todd[1]
> 
> 
> On Thu, Feb 24, 2011 at 7:17 PM, John Purrier <john@xxxxxxxxxxxxx>
> wrote:
> > 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
> >
> >
> > _______________________________________________
> > 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