openstack team mailing list archive

[Todd Willey <todd@xxxxxxxxxxxx>]

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.

-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
>