Re: [Openstack] OpenStack Client Followup

[Doug Hellmann]

On Wed, May 2, 2012 at 6:01 PM, Doug Hellmann
wrote:

>
>
> On Wed, May 2, 2012 at 1:23 PM, Adam Spiers  wrote:
>
>> Dean Troyer (dtro...@gmail.com) wrote:
>> > On Tue, May 1, 2012 at 2:11 PM, Adam Spiers  wrote:
>> > > As of my recent patch, --help is contextual in nova:
>> >
>> > I hadn't seen that yet...
>> >
>> > > and I have started work on some of the other commands too, so it would
>> > > be helpful if we could reach a consensus on this soon ... although
>> > > please let me know if I am wasting my time working on other commands
>> > > due to any imminent rewrites using python-openstack!
>> >
>> > The continued existence of the project-specific commands is really up
>> > to the projects themselves.  I think it would be great to converge
>> > them on things like this, but trying to get them all to work the same
>> > is what led us to openstackclient due to backward compatibility and
>> > all.  My guess would be that the existing client binaries would live
>> > through the 'G' release even if we decided to deprecate them now.
>>
>> OK, thanks for the info.  So what's the goal for this project - to
>> enter the incubation program? to become part of openstack-common?
>> Should it be added to http://wiki.openstack.org/Projects ?
>>
>> > > I agree with Dolph - there is a precedent from other well-known
>> > > programs (git, hg, svn are the first ones I can think of) for --help
>> > > to behave differently depending on whether or not it was preceded by a
>> > > subcommand.  So my vote is that we should definitely aim to adhere to
>> > > this pattern.
>> >
>> > How about detailing it in the HIG and once we get a command or two
>> > implemented with argument parsing we give it a shot?
>>
>> I took a stab at this, but it's beginning to confirm the doubts which
>> I wrote about in https://lists.launchpad.net/openstack/msg10956.html
>> regarding the decision to have the verb preceding the noun:
>>
>>openstack create --help
>>openstack help create
>>
>> would require grouping of help for all the creation actions together
>> which doesn't make much sense to me.  These both seem to make more
>> sense:
>>
>>openstack endpoint --help
>>openstack help endpoint
>>
> but would lead to overly long output unless they invoked man(1) on a
>> corresponding manual page all about endpoint management, similar to
>> how say, 'git remote --help' invokes the git-remote(1) man page which
>> covers management of git remotes.
>>
>> The other option is to support a more fine-grained approach to help:
>>
>>openstack create endpoint --help
>>openstack help create endpoint
>>
>> and then make the help action require both, e.g.
>>
>>$ openstack help create
>>Usage: openstack help create OBJECT-TYPE
>>
>>Which type of object do you want help creating?
>>
>>Available identity types:
>>catalog ec2-credentials endpoint role
>>service tenant  user user-password
>>user-role
>>
>>Available compute types:
>>absolute-limits actions aggregatebash-completion
>>cloudpipe   console-log credentials  diagnostics
>>dns dns-domain  endpointsfixed-ip
>>flavor  floating-ip floating-ip-pool host
>>image   keypair meta(data)   quota
>>quota-class rate-limits resource root-password
>>secgroupsecgroup-group  secgroup-ruleusage
>>vnc-console volume  volume-snapshot  volume-type
>>x509-cert   x509-root-cert
>>
>>[...]
>>
>> and ditto for 'openstack create --help'.  (Of course, this is just a
>> mockup and incorrectly lists some types which you would never create.)
>>
>> Here are the classes of use cases I can think of:
>>
>>  1. User has never/rarely used the (openstack) command before and
>> needs to know overall structure of possible arguments and/or see
>> a brief summary of common "get me started" arguments.
>>
>> Suggested implementation:
>> openstack --help
>>
>>  2. User has used the (openstack) command before but needs to check
>> global options.
>>
>> Suggested implementation:
>> openstack --help
>>
>
> FTR, both 1 and 2 are implemented today.
>
>
>>
>>  3. User wants to e.g. create something but isn't sure of the exact
>> name of the type of the object to be created.
>>
>> Suggested implementation:
>> openstack help create
>> openstack create --help
>>
>
> It should be relatively straightforward to have the help command scan all
> available commands using the input as a substring if it doesn't match
> anything exactly. I think we probably just want to produce the list of
> those commands, though, and not go into any more detail than a one-line
> description. Doing much more is going to produce far too much output.
>

https://github.com/dreamhost/cliff/issues/8


>
>
>>
>>  4. User wa

Re: [Openstack] OpenStack Client Followup

[Doug Hellmann]

On Wed, May 2, 2012 at 1:23 PM, Adam Spiers  wrote:

> Dean Troyer (dtro...@gmail.com) wrote:
> > On Tue, May 1, 2012 at 2:11 PM, Adam Spiers  wrote:
> > > As of my recent patch, --help is contextual in nova:
> >
> > I hadn't seen that yet...
> >
> > > and I have started work on some of the other commands too, so it would
> > > be helpful if we could reach a consensus on this soon ... although
> > > please let me know if I am wasting my time working on other commands
> > > due to any imminent rewrites using python-openstack!
> >
> > The continued existence of the project-specific commands is really up
> > to the projects themselves.  I think it would be great to converge
> > them on things like this, but trying to get them all to work the same
> > is what led us to openstackclient due to backward compatibility and
> > all.  My guess would be that the existing client binaries would live
> > through the 'G' release even if we decided to deprecate them now.
>
> OK, thanks for the info.  So what's the goal for this project - to
> enter the incubation program? to become part of openstack-common?
> Should it be added to http://wiki.openstack.org/Projects ?
>
> > > I agree with Dolph - there is a precedent from other well-known
> > > programs (git, hg, svn are the first ones I can think of) for --help
> > > to behave differently depending on whether or not it was preceded by a
> > > subcommand.  So my vote is that we should definitely aim to adhere to
> > > this pattern.
> >
> > How about detailing it in the HIG and once we get a command or two
> > implemented with argument parsing we give it a shot?
>
> I took a stab at this, but it's beginning to confirm the doubts which
> I wrote about in https://lists.launchpad.net/openstack/msg10956.html
> regarding the decision to have the verb preceding the noun:
>
>openstack create --help
>openstack help create
>
> would require grouping of help for all the creation actions together
> which doesn't make much sense to me.  These both seem to make more
> sense:
>
>openstack endpoint --help
>openstack help endpoint
>
but would lead to overly long output unless they invoked man(1) on a
> corresponding manual page all about endpoint management, similar to
> how say, 'git remote --help' invokes the git-remote(1) man page which
> covers management of git remotes.
>
> The other option is to support a more fine-grained approach to help:
>
>openstack create endpoint --help
>openstack help create endpoint
>
> and then make the help action require both, e.g.
>
>$ openstack help create
>Usage: openstack help create OBJECT-TYPE
>
>Which type of object do you want help creating?
>
>Available identity types:
>catalog ec2-credentials endpoint role
>service tenant  user user-password
>user-role
>
>Available compute types:
>absolute-limits actions aggregatebash-completion
>cloudpipe   console-log credentials  diagnostics
>dns dns-domain  endpointsfixed-ip
>flavor  floating-ip floating-ip-pool host
>image   keypair meta(data)   quota
>quota-class rate-limits resource root-password
>secgroupsecgroup-group  secgroup-ruleusage
>vnc-console volume  volume-snapshot  volume-type
>x509-cert   x509-root-cert
>
>[...]
>
> and ditto for 'openstack create --help'.  (Of course, this is just a
> mockup and incorrectly lists some types which you would never create.)
>
> Here are the classes of use cases I can think of:
>
>  1. User has never/rarely used the (openstack) command before and
> needs to know overall structure of possible arguments and/or see
> a brief summary of common "get me started" arguments.
>
> Suggested implementation:
> openstack --help
>
>  2. User has used the (openstack) command before but needs to check
> global options.
>
> Suggested implementation:
> openstack --help
>

FTR, both 1 and 2 are implemented today.


>
>  3. User wants to e.g. create something but isn't sure of the exact
> name of the type of the object to be created.
>
> Suggested implementation:
> openstack help create
> openstack create --help
>

It should be relatively straightforward to have the help command scan all
available commands using the input as a substring if it doesn't match
anything exactly. I think we probably just want to produce the list of
those commands, though, and not go into any more detail than a one-line
description. Doing much more is going to produce far too much output.


>
>  4. User wants to perform one or more actions on a particular type of
> object e.g. volume, but isn't sure which actions are available.
>
> Suggested implementation:
> 
>

See comment above.


>
>  5. User knows both the action 

Re: [Openstack] OpenStack Client Followup

[Duncan McGreggor]

You make some fair points.

But consider the large class of cloud users that will never need to
bring up OpenStack from scratch, but rather maintain them. These users
will need to be able to easily identify the commands that pertain to
their daily maintenance, troubleshooting, and reporting tasks. Design
of a CLI tool for different audiences is just as important as visual
interface design.

However, anticipating that now, before we have solid usage data, may
be premature.

In order to eventually deliver improved organization of CLI commands
and a good usability experience for all classes of users, I'd ask that
we at least leave room in the design of these tools such that
improving the command organization later will be a trivial task.

d

On Wed, May 2, 2012 at 9:14 AM, Dolph Mathews  wrote:
> I disagree with all three... the line between "admin" and "not admin" is
> going to get very blurry in the long run. Example: I may be a regular user,
> but I've been granted what is "normally" an admin capability on tenant X.
> Does that make me an admin? Do I now need to use two different clients?
>
> I also don't think it should be the client's *responsibility* to understand
> what capabilities are required for any given command (ultimately making
> *assumptions* about what the service will allow the user to do), as it's the
> remote service that's ultimately going to enforce it's own policies. It may
> be a decent feature to warn the user something is probably not going to work
> (or better yet, the ability to ask the remote service if something will
> succeed before we attempt it), but the client shouldn't prevent the user
> from trying -- especially by suppressing/isolating features. Horizon is
> going to face the same challenge (hiding/showing capability-relevant UI).
>
> tl;dr: openstackclient should be uniformly featured across all OpenStack
> API's ("service", "admin" or otherwise)
>
> -Dolph
>
> On Tue, May 1, 2012 at 6:55 PM, Doug Hellmann 
> wrote:
>>
>> There are a couple of ways to handle that:
>>
>> 1. A separate "openstackadmin" CLI that looks for commands using a
>> different plugin namespace, and therefore only loads the admin commands.
>>
>> 2. Prefix admin-related commands in the unified cli with "admin" (so
>> "openstack admin create network" or whatever).
>>
>> 3. Separate admin apps for each project.
>>
>> I think we should avoid 3, since that goes against the spirit of this
>> project. I like #2, but #1 would be easy to implement and could share 99% of
>> the code from the basic openstackclient.
>>
>> On Tue, May 1, 2012 at 4:59 PM, Matt Joyce  wrote:
>>>
>>> How does this blueprint play into this client.  Is it a separate admin
>>> only client or just a subset of this guy?
>>>
>>> https://blueprints.launchpad.net/nova/+spec/admin-cli
>>>
>>> -matt
>>>
>>> On Tue, May 1, 2012 at 12:28 PM, Dean Troyer  wrote:
>>> > On Tue, May 1, 2012 at 2:11 PM, Adam Spiers  wrote:
>>> >> As of my recent patch, --help is contextual in nova:
>>> >
>>> > I hadn't seen that yet...
>>> >
>>> >> and I have started work on some of the other commands too, so it would
>>> >> be helpful if we could reach a consensus on this soon ... although
>>> >> please let me know if I am wasting my time working on other commands
>>> >> due to any imminent rewrites using python-openstack!
>>> >
>>> > The continued existence of the project-specific commands is really up
>>> > to the projects themselves.  I think it would be great to converge
>>> > them on things like this, but trying to get them all to work the same
>>> > is what led us to openstackclient due to backward compatibility and
>>> > all.  My guess would be that the existing client binaries would live
>>> > through the 'G' release even if we decided to deprecate them now.
>>> >
>>> >> I agree with Dolph - there is a precedent from other well-known
>>> >> programs (git, hg, svn are the first ones I can think of) for --help
>>> >> to behave differently depending on whether or not it was preceded by a
>>> >> subcommand.  So my vote is that we should definitely aim to adhere to
>>> >> this pattern.
>>> >
>>> > How about detailing it in the HIG and once we get a command or two
>>> > implemented with argument parsing we give it a shot?
>>> >
>>> > dt
>>> >
>>> > --
>>> >
>>> > Dean Troyer
>>> > dtro...@gmail.com
>>> >
>>> > ___
>>> > Mailing list: https://launchpad.net/~openstack
>>> > Post to     : openstack@lists.launchpad.net
>>> > Unsubscribe : https://launchpad.net/~openstack
>>> > More help   : https://help.launchpad.net/ListHelp
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to     : openstack@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@lists.lau

Re: [Openstack] OpenStack Client Followup

[Duncan McGreggor]

On Tue, May 1, 2012 at 7:55 PM, Doug Hellmann
 wrote:
> There are a couple of ways to handle that:
>
> 1. A separate "openstackadmin" CLI that looks for commands using a different
> plugin namespace, and therefore only loads the admin commands.
>
> 2. Prefix admin-related commands in the unified cli with "admin" (so
> "openstack admin create network" or whatever).

+1 on this proposition.

d

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

Re: [Openstack] OpenStack Client Followup

[Adam Spiers]

Dean Troyer (dtro...@gmail.com) wrote:
> On Tue, May 1, 2012 at 2:11 PM, Adam Spiers  wrote:
> > As of my recent patch, --help is contextual in nova:
> 
> I hadn't seen that yet...
> 
> > and I have started work on some of the other commands too, so it would
> > be helpful if we could reach a consensus on this soon ... although
> > please let me know if I am wasting my time working on other commands
> > due to any imminent rewrites using python-openstack!
> 
> The continued existence of the project-specific commands is really up
> to the projects themselves.  I think it would be great to converge
> them on things like this, but trying to get them all to work the same
> is what led us to openstackclient due to backward compatibility and
> all.  My guess would be that the existing client binaries would live
> through the 'G' release even if we decided to deprecate them now.

OK, thanks for the info.  So what's the goal for this project - to
enter the incubation program? to become part of openstack-common?
Should it be added to http://wiki.openstack.org/Projects ?

> > I agree with Dolph - there is a precedent from other well-known
> > programs (git, hg, svn are the first ones I can think of) for --help
> > to behave differently depending on whether or not it was preceded by a
> > subcommand.  So my vote is that we should definitely aim to adhere to
> > this pattern.
> 
> How about detailing it in the HIG and once we get a command or two
> implemented with argument parsing we give it a shot?

I took a stab at this, but it's beginning to confirm the doubts which
I wrote about in https://lists.launchpad.net/openstack/msg10956.html
regarding the decision to have the verb preceding the noun:

openstack create --help
openstack help create

would require grouping of help for all the creation actions together
which doesn't make much sense to me.  These both seem to make more
sense:

openstack endpoint --help
openstack help endpoint

but would lead to overly long output unless they invoked man(1) on a
corresponding manual page all about endpoint management, similar to
how say, 'git remote --help' invokes the git-remote(1) man page which
covers management of git remotes.

The other option is to support a more fine-grained approach to help:

openstack create endpoint --help
openstack help create endpoint

and then make the help action require both, e.g.

$ openstack help create
Usage: openstack help create OBJECT-TYPE

Which type of object do you want help creating?

Available identity types:
catalog ec2-credentials endpoint role
service tenant  user user-password
user-role

Available compute types:
absolute-limits actions aggregatebash-completion
cloudpipe   console-log credentials  diagnostics
dns dns-domain  endpointsfixed-ip
flavor  floating-ip floating-ip-pool host
image   keypair meta(data)   quota
quota-class rate-limits resource root-password
secgroupsecgroup-group  secgroup-ruleusage
vnc-console volume  volume-snapshot  volume-type
x509-cert   x509-root-cert

[...]

and ditto for 'openstack create --help'.  (Of course, this is just a
mockup and incorrectly lists some types which you would never create.)

Here are the classes of use cases I can think of:

  1. User has never/rarely used the (openstack) command before and
 needs to know overall structure of possible arguments and/or see
 a brief summary of common "get me started" arguments.

 Suggested implementation:
 openstack --help

  2. User has used the (openstack) command before but needs to check
 global options.

 Suggested implementation:
 openstack --help

  3. User wants to e.g. create something but isn't sure of the exact
 name of the type of the object to be created.

 Suggested implementation:
 openstack help create
 openstack create --help

  4. User wants to perform one or more actions on a particular type of
 object e.g. volume, but isn't sure which actions are available.

 Suggested implementation:
 

  5. User knows both the action and object type but needs to check
 details of options / extra positional arguments.

 Suggested implementation:
 openstack create endpoint --help
 openstack help create endpoint

Thoughts?

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

Re: [Openstack] OpenStack Client Followup

[Doug Hellmann]

On Wed, May 2, 2012 at 10:40 AM, Adam Spiers  wrote:

> Dean Troyer (dtro...@gmail.com) wrote:
> > On Tue, May 1, 2012 at 12:54 PM, Adam Spiers  wrote:
> > > Agreed - while server-side auditing is a more important component than
> > > client-side, having both sounds potentially useful to me too.  And
> > > while it's outside the scope of a CLI HIG discussion, it's
> > > nevertheless relevant to any work on a unified CLI.
> >
> > Sounds like a blueprint waiting to be written... ;)
>
> I think Doug just captured that one:
>
>
> https://blueprints.launchpad.net/python-openstackclient/+spec/command-history


Matt got that one. The logging built into cliff may be useful for the
capture. The input arguments aren't logged right now, but it would be easy
to add that step.
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] OpenStack Client Followup

[Dolph Mathews]

I don't think any clients truly implement this behavior *yet*, but each
service should return a multiple choice response (e.g.
http://keystone.openstack.org/api_curl_examples.html#id2 ) containing links
to each API version (/v1, /v2, /v3), and their status (e.g. deprecated,
current, beta, etc). Ideally the client should automatically use the latest
stable endpoint it understands, and allow the user to override the
selection.

-Dolph

On Wed, May 2, 2012 at 9:58 AM, Matt Joyce  wrote:

> Actually this ties into a thought I was having this morning.
>
> How do we handle API versioning?  I mean I would assume that we'd want
> to poll the API server and see which versions are available and offer
> command sets that are relevant.  Silencing API version specific
> commands that are not available as well as administrative commands
> that are not as well seems wholly feasible depending on how we are
> tracking API versioning inside of the client.
>
> So I suppose the question is... how does the client approach API
> versioning?
>
> -Matt
>
> On Wed, May 2, 2012 at 6:14 AM, Dolph Mathews 
> wrote:
> > I disagree with all three... the line between "admin" and "not admin" is
> > going to get very blurry in the long run. Example: I may be a regular
> user,
> > but I've been granted what is "normally" an admin capability on tenant X.
> > Does that make me an admin? Do I now need to use two different clients?
> >
> > I also don't think it should be the client's *responsibility* to
> understand
> > what capabilities are required for any given command (ultimately making
> > *assumptions* about what the service will allow the user to do), as it's
> the
> > remote service that's ultimately going to enforce it's own policies. It
> may
> > be a decent feature to warn the user something is probably not going to
> work
> > (or better yet, the ability to ask the remote service if something will
> > succeed before we attempt it), but the client shouldn't prevent the user
> > from trying -- especially by suppressing/isolating features. Horizon is
> > going to face the same challenge (hiding/showing capability-relevant UI).
> >
> > tl;dr: openstackclient should be uniformly featured across all OpenStack
> > API's ("service", "admin" or otherwise)
> >
> > -Dolph
> >
> > On Tue, May 1, 2012 at 6:55 PM, Doug Hellmann <
> doug.hellm...@dreamhost.com>
> > wrote:
> >>
> >> There are a couple of ways to handle that:
> >>
> >> 1. A separate "openstackadmin" CLI that looks for commands using a
> >> different plugin namespace, and therefore only loads the admin commands.
> >>
> >> 2. Prefix admin-related commands in the unified cli with "admin" (so
> >> "openstack admin create network" or whatever).
> >>
> >> 3. Separate admin apps for each project.
> >>
> >> I think we should avoid 3, since that goes against the spirit of this
> >> project. I like #2, but #1 would be easy to implement and could share
> 99% of
> >> the code from the basic openstackclient.
> >>
> >> On Tue, May 1, 2012 at 4:59 PM, Matt Joyce 
> wrote:
> >>>
> >>> How does this blueprint play into this client.  Is it a separate admin
> >>> only client or just a subset of this guy?
> >>>
> >>> https://blueprints.launchpad.net/nova/+spec/admin-cli
> >>>
> >>> -matt
> >>>
> >>> On Tue, May 1, 2012 at 12:28 PM, Dean Troyer 
> wrote:
> >>> > On Tue, May 1, 2012 at 2:11 PM, Adam Spiers 
> wrote:
> >>> >> As of my recent patch, --help is contextual in nova:
> >>> >
> >>> > I hadn't seen that yet...
> >>> >
> >>> >> and I have started work on some of the other commands too, so it
> would
> >>> >> be helpful if we could reach a consensus on this soon ... although
> >>> >> please let me know if I am wasting my time working on other commands
> >>> >> due to any imminent rewrites using python-openstack!
> >>> >
> >>> > The continued existence of the project-specific commands is really up
> >>> > to the projects themselves.  I think it would be great to converge
> >>> > them on things like this, but trying to get them all to work the same
> >>> > is what led us to openstackclient due to backward compatibility and
> >>> > all.  My guess would be that the existing client binaries would live
> >>> > through the 'G' release even if we decided to deprecate them now.
> >>> >
> >>> >> I agree with Dolph - there is a precedent from other well-known
> >>> >> programs (git, hg, svn are the first ones I can think of) for --help
> >>> >> to behave differently depending on whether or not it was preceded
> by a
> >>> >> subcommand.  So my vote is that we should definitely aim to adhere
> to
> >>> >> this pattern.
> >>> >
> >>> > How about detailing it in the HIG and once we get a command or two
> >>> > implemented with argument parsing we give it a shot?
> >>> >
> >>> > dt
> >>> >
> >>> > --
> >>> >
> >>> > Dean Troyer
> >>> > dtro...@gmail.com
> >>> >
> >>> > ___
> >>> > Mailing list: https://launchpad.net/~openstack
> >>> > Post to : openstack@lists.launc

Re: [Openstack] OpenStack Client Followup

[Matt Joyce]

Actually this ties into a thought I was having this morning.

How do we handle API versioning?  I mean I would assume that we'd want
to poll the API server and see which versions are available and offer
command sets that are relevant.  Silencing API version specific
commands that are not available as well as administrative commands
that are not as well seems wholly feasible depending on how we are
tracking API versioning inside of the client.

So I suppose the question is... how does the client approach API versioning?

-Matt

On Wed, May 2, 2012 at 6:14 AM, Dolph Mathews  wrote:
> I disagree with all three... the line between "admin" and "not admin" is
> going to get very blurry in the long run. Example: I may be a regular user,
> but I've been granted what is "normally" an admin capability on tenant X.
> Does that make me an admin? Do I now need to use two different clients?
>
> I also don't think it should be the client's *responsibility* to understand
> what capabilities are required for any given command (ultimately making
> *assumptions* about what the service will allow the user to do), as it's the
> remote service that's ultimately going to enforce it's own policies. It may
> be a decent feature to warn the user something is probably not going to work
> (or better yet, the ability to ask the remote service if something will
> succeed before we attempt it), but the client shouldn't prevent the user
> from trying -- especially by suppressing/isolating features. Horizon is
> going to face the same challenge (hiding/showing capability-relevant UI).
>
> tl;dr: openstackclient should be uniformly featured across all OpenStack
> API's ("service", "admin" or otherwise)
>
> -Dolph
>
> On Tue, May 1, 2012 at 6:55 PM, Doug Hellmann 
> wrote:
>>
>> There are a couple of ways to handle that:
>>
>> 1. A separate "openstackadmin" CLI that looks for commands using a
>> different plugin namespace, and therefore only loads the admin commands.
>>
>> 2. Prefix admin-related commands in the unified cli with "admin" (so
>> "openstack admin create network" or whatever).
>>
>> 3. Separate admin apps for each project.
>>
>> I think we should avoid 3, since that goes against the spirit of this
>> project. I like #2, but #1 would be easy to implement and could share 99% of
>> the code from the basic openstackclient.
>>
>> On Tue, May 1, 2012 at 4:59 PM, Matt Joyce  wrote:
>>>
>>> How does this blueprint play into this client.  Is it a separate admin
>>> only client or just a subset of this guy?
>>>
>>> https://blueprints.launchpad.net/nova/+spec/admin-cli
>>>
>>> -matt
>>>
>>> On Tue, May 1, 2012 at 12:28 PM, Dean Troyer  wrote:
>>> > On Tue, May 1, 2012 at 2:11 PM, Adam Spiers  wrote:
>>> >> As of my recent patch, --help is contextual in nova:
>>> >
>>> > I hadn't seen that yet...
>>> >
>>> >> and I have started work on some of the other commands too, so it would
>>> >> be helpful if we could reach a consensus on this soon ... although
>>> >> please let me know if I am wasting my time working on other commands
>>> >> due to any imminent rewrites using python-openstack!
>>> >
>>> > The continued existence of the project-specific commands is really up
>>> > to the projects themselves.  I think it would be great to converge
>>> > them on things like this, but trying to get them all to work the same
>>> > is what led us to openstackclient due to backward compatibility and
>>> > all.  My guess would be that the existing client binaries would live
>>> > through the 'G' release even if we decided to deprecate them now.
>>> >
>>> >> I agree with Dolph - there is a precedent from other well-known
>>> >> programs (git, hg, svn are the first ones I can think of) for --help
>>> >> to behave differently depending on whether or not it was preceded by a
>>> >> subcommand.  So my vote is that we should definitely aim to adhere to
>>> >> this pattern.
>>> >
>>> > How about detailing it in the HIG and once we get a command or two
>>> > implemented with argument parsing we give it a shot?
>>> >
>>> > dt
>>> >
>>> > --
>>> >
>>> > Dean Troyer
>>> > dtro...@gmail.com
>>> >
>>> > ___
>>> > Mailing list: https://launchpad.net/~openstack
>>> > Post to     : openstack@lists.launchpad.net
>>> > Unsubscribe : https://launchpad.net/~openstack
>>> > More help   : https://help.launchpad.net/ListHelp
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to     : openstack@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>

___
Mailing list: https://launchpad.net/~openstack
P

Re: [Openstack] OpenStack Client Followup

[Adam Spiers]

Dean Troyer (dtro...@gmail.com) wrote:
> On Tue, May 1, 2012 at 12:54 PM, Adam Spiers  wrote:
> > Agreed - while server-side auditing is a more important component than
> > client-side, having both sounds potentially useful to me too.  And
> > while it's outside the scope of a CLI HIG discussion, it's
> > nevertheless relevant to any work on a unified CLI.
> 
> Sounds like a blueprint waiting to be written... ;)

I think Doug just captured that one:

https://blueprints.launchpad.net/python-openstackclient/+spec/command-history

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

Re: [Openstack] OpenStack Client Followup

[Dolph Mathews]

I disagree with all three... the line between "admin" and "not admin" is
going to get very blurry in the long run. Example: I may be a regular user,
but I've been granted what is "normally" an admin capability on tenant X.
Does that make me an admin? Do I now need to use two different clients?

I also don't think it should be the client's *responsibility* to understand
what capabilities are required for any given command (ultimately making
*assumptions* about what the service will allow the user to do), as it's
the remote service that's ultimately going to enforce it's own policies. It
may be a decent feature to warn the user something is probably not going to
work (or better yet, the ability to ask the remote service if something
will succeed before we attempt it), but the client shouldn't prevent the
user from trying -- especially by suppressing/isolating features. Horizon
is going to face the same challenge (hiding/showing capability-relevant UI).

tl;dr: openstackclient should be uniformly featured across all OpenStack
API's ("service", "admin" or otherwise)

-Dolph

On Tue, May 1, 2012 at 6:55 PM, Doug Hellmann
wrote:

> There are a couple of ways to handle that:
>
> 1. A separate "openstackadmin" CLI that looks for commands using a
> different plugin namespace, and therefore only loads the admin commands.
>
> 2. Prefix admin-related commands in the unified cli with "admin" (so
> "openstack admin create network" or whatever).
>
> 3. Separate admin apps for each project.
>
> I think we should avoid 3, since that goes against the spirit of this
> project. I like #2, but #1 would be easy to implement and could share 99%
> of the code from the basic openstackclient.
>
> On Tue, May 1, 2012 at 4:59 PM, Matt Joyce  wrote:
>
>> How does this blueprint play into this client.  Is it a separate admin
>> only client or just a subset of this guy?
>>
>> https://blueprints.launchpad.net/nova/+spec/admin-cli
>>
>> -matt
>>
>> On Tue, May 1, 2012 at 12:28 PM, Dean Troyer  wrote:
>> > On Tue, May 1, 2012 at 2:11 PM, Adam Spiers  wrote:
>> >> As of my recent patch, --help is contextual in nova:
>> >
>> > I hadn't seen that yet...
>> >
>> >> and I have started work on some of the other commands too, so it would
>> >> be helpful if we could reach a consensus on this soon ... although
>> >> please let me know if I am wasting my time working on other commands
>> >> due to any imminent rewrites using python-openstack!
>> >
>> > The continued existence of the project-specific commands is really up
>> > to the projects themselves.  I think it would be great to converge
>> > them on things like this, but trying to get them all to work the same
>> > is what led us to openstackclient due to backward compatibility and
>> > all.  My guess would be that the existing client binaries would live
>> > through the 'G' release even if we decided to deprecate them now.
>> >
>> >> I agree with Dolph - there is a precedent from other well-known
>> >> programs (git, hg, svn are the first ones I can think of) for --help
>> >> to behave differently depending on whether or not it was preceded by a
>> >> subcommand.  So my vote is that we should definitely aim to adhere to
>> >> this pattern.
>> >
>> > How about detailing it in the HIG and once we get a command or two
>> > implemented with argument parsing we give it a shot?
>> >
>> > dt
>> >
>> > --
>> >
>> > Dean Troyer
>> > dtro...@gmail.com
>> >
>> > ___
>> > Mailing list: https://launchpad.net/~openstack
>> > Post to : openstack@lists.launchpad.net
>> > Unsubscribe : https://launchpad.net/~openstack
>> > More help   : https://help.launchpad.net/ListHelp
>>
>> ___
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] OpenStack Client Followup

[Joshua Harlow]

I like #1, if the admin plugins aren't there then u don't get admin commands. 
Plus it makes a lot of the same code be used in both cases.


On 5/1/12 4:55 PM, "Doug Hellmann"  wrote:

There are a couple of ways to handle that:

1. A separate "openstackadmin" CLI that looks for commands using a different 
plugin namespace, and therefore only loads the admin commands.

2. Prefix admin-related commands in the unified cli with "admin" (so "openstack 
admin create network" or whatever).

3. Separate admin apps for each project.

I think we should avoid 3, since that goes against the spirit of this project. 
I like #2, but #1 would be easy to implement and could share 99% of the code 
from the basic openstackclient.

On Tue, May 1, 2012 at 4:59 PM, Matt Joyce  wrote:
How does this blueprint play into this client.  Is it a separate admin
only client or just a subset of this guy?

https://blueprints.launchpad.net/nova/+spec/admin-cli

-matt

On Tue, May 1, 2012 at 12:28 PM, Dean Troyer  wrote:
> On Tue, May 1, 2012 at 2:11 PM, Adam Spiers  wrote:
>> As of my recent patch, --help is contextual in nova:
>
> I hadn't seen that yet...
>
>> and I have started work on some of the other commands too, so it would
>> be helpful if we could reach a consensus on this soon ... although
>> please let me know if I am wasting my time working on other commands
>> due to any imminent rewrites using python-openstack!
>
> The continued existence of the project-specific commands is really up
> to the projects themselves.  I think it would be great to converge
> them on things like this, but trying to get them all to work the same
> is what led us to openstackclient due to backward compatibility and
> all.  My guess would be that the existing client binaries would live
> through the 'G' release even if we decided to deprecate them now.
>
>> I agree with Dolph - there is a precedent from other well-known
>> programs (git, hg, svn are the first ones I can think of) for --help
>> to behave differently depending on whether or not it was preceded by a
>> subcommand.  So my vote is that we should definitely aim to adhere to
>> this pattern.
>
> How about detailing it in the HIG and once we get a command or two
> implemented with argument parsing we give it a shot?
>
> dt
>
> --
>
> Dean Troyer
> dtro...@gmail.com
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

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


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

Re: [Openstack] OpenStack Client Followup

[Matt Joyce]

Optimally the admin commands wouldn't even show up unless you had a
proper token.   In interactive we can do an initial query and check
privs and establish a list of operators allowed.

-Matt

On Tue, May 1, 2012 at 4:55 PM, Doug Hellmann
 wrote:
> There are a couple of ways to handle that:
>
> 1. A separate "openstackadmin" CLI that looks for commands using a different
> plugin namespace, and therefore only loads the admin commands.
>
> 2. Prefix admin-related commands in the unified cli with "admin" (so
> "openstack admin create network" or whatever).
>
> 3. Separate admin apps for each project.
>
> I think we should avoid 3, since that goes against the spirit of this
> project. I like #2, but #1 would be easy to implement and could share 99% of
> the code from the basic openstackclient.
>
> On Tue, May 1, 2012 at 4:59 PM, Matt Joyce  wrote:
>>
>> How does this blueprint play into this client.  Is it a separate admin
>> only client or just a subset of this guy?
>>
>> https://blueprints.launchpad.net/nova/+spec/admin-cli
>>
>> -matt
>>
>> On Tue, May 1, 2012 at 12:28 PM, Dean Troyer  wrote:
>> > On Tue, May 1, 2012 at 2:11 PM, Adam Spiers  wrote:
>> >> As of my recent patch, --help is contextual in nova:
>> >
>> > I hadn't seen that yet...
>> >
>> >> and I have started work on some of the other commands too, so it would
>> >> be helpful if we could reach a consensus on this soon ... although
>> >> please let me know if I am wasting my time working on other commands
>> >> due to any imminent rewrites using python-openstack!
>> >
>> > The continued existence of the project-specific commands is really up
>> > to the projects themselves.  I think it would be great to converge
>> > them on things like this, but trying to get them all to work the same
>> > is what led us to openstackclient due to backward compatibility and
>> > all.  My guess would be that the existing client binaries would live
>> > through the 'G' release even if we decided to deprecate them now.
>> >
>> >> I agree with Dolph - there is a precedent from other well-known
>> >> programs (git, hg, svn are the first ones I can think of) for --help
>> >> to behave differently depending on whether or not it was preceded by a
>> >> subcommand.  So my vote is that we should definitely aim to adhere to
>> >> this pattern.
>> >
>> > How about detailing it in the HIG and once we get a command or two
>> > implemented with argument parsing we give it a shot?
>> >
>> > dt
>> >
>> > --
>> >
>> > Dean Troyer
>> > dtro...@gmail.com
>> >
>> > ___
>> > Mailing list: https://launchpad.net/~openstack
>> > Post to     : openstack@lists.launchpad.net
>> > Unsubscribe : https://launchpad.net/~openstack
>> > More help   : https://help.launchpad.net/ListHelp
>>
>> ___
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>
>

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

Re: [Openstack] OpenStack Client Followup

[Doug Hellmann]

There are a couple of ways to handle that:

1. A separate "openstackadmin" CLI that looks for commands using a
different plugin namespace, and therefore only loads the admin commands.

2. Prefix admin-related commands in the unified cli with "admin" (so
"openstack admin create network" or whatever).

3. Separate admin apps for each project.

I think we should avoid 3, since that goes against the spirit of this
project. I like #2, but #1 would be easy to implement and could share 99%
of the code from the basic openstackclient.

On Tue, May 1, 2012 at 4:59 PM, Matt Joyce  wrote:

> How does this blueprint play into this client.  Is it a separate admin
> only client or just a subset of this guy?
>
> https://blueprints.launchpad.net/nova/+spec/admin-cli
>
> -matt
>
> On Tue, May 1, 2012 at 12:28 PM, Dean Troyer  wrote:
> > On Tue, May 1, 2012 at 2:11 PM, Adam Spiers  wrote:
> >> As of my recent patch, --help is contextual in nova:
> >
> > I hadn't seen that yet...
> >
> >> and I have started work on some of the other commands too, so it would
> >> be helpful if we could reach a consensus on this soon ... although
> >> please let me know if I am wasting my time working on other commands
> >> due to any imminent rewrites using python-openstack!
> >
> > The continued existence of the project-specific commands is really up
> > to the projects themselves.  I think it would be great to converge
> > them on things like this, but trying to get them all to work the same
> > is what led us to openstackclient due to backward compatibility and
> > all.  My guess would be that the existing client binaries would live
> > through the 'G' release even if we decided to deprecate them now.
> >
> >> I agree with Dolph - there is a precedent from other well-known
> >> programs (git, hg, svn are the first ones I can think of) for --help
> >> to behave differently depending on whether or not it was preceded by a
> >> subcommand.  So my vote is that we should definitely aim to adhere to
> >> this pattern.
> >
> > How about detailing it in the HIG and once we get a command or two
> > implemented with argument parsing we give it a shot?
> >
> > dt
> >
> > --
> >
> > Dean Troyer
> > dtro...@gmail.com
> >
> > ___
> > Mailing list: https://launchpad.net/~openstack
> > Post to : openstack@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~openstack
> > More help   : https://help.launchpad.net/ListHelp
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] OpenStack Client Followup

[Matt Joyce]

> As far as whether we support admin-only commands, I think we should.
> If they have their own client libs then we'll split them up too.  I
> actually kind of liked the side effect of the old nova-manage in that
> it was self-enforcing for admin-ness since you needed to run it on the
> node itself.

I think federation may drive us away from that sort of isolation.
And, eventually drive us right back to it in some other container.

-Matt

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

Re: [Openstack] OpenStack Client Followup

[Dean Troyer]

On Tue, May 1, 2012 at 3:59 PM, Matt Joyce  wrote:
> How does this blueprint play into this client.  Is it a separate admin
> only client or just a subset of this guy?
> https://blueprints.launchpad.net/nova/+spec/admin-cli

Since we are consumers of the python-novaclient API libraries we need
to track the movement of the admin stuff.  That particular blueprint
has not been targeted yet so we don't know if it will be implemented
in folsom.

As far as whether we support admin-only commands, I think we should.
If they have their own client libs then we'll split them up too.  I
actually kind of liked the side effect of the old nova-manage in that
it was self-enforcing for admin-ness since you needed to run it on the
node itself.

dt

-- 

Dean Troyer
dtro...@gmail.com

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

Re: [Openstack] OpenStack Client Followup

[Matt Joyce]

How does this blueprint play into this client.  Is it a separate admin
only client or just a subset of this guy?

https://blueprints.launchpad.net/nova/+spec/admin-cli

-matt

On Tue, May 1, 2012 at 12:28 PM, Dean Troyer  wrote:
> On Tue, May 1, 2012 at 2:11 PM, Adam Spiers  wrote:
>> As of my recent patch, --help is contextual in nova:
>
> I hadn't seen that yet...
>
>> and I have started work on some of the other commands too, so it would
>> be helpful if we could reach a consensus on this soon ... although
>> please let me know if I am wasting my time working on other commands
>> due to any imminent rewrites using python-openstack!
>
> The continued existence of the project-specific commands is really up
> to the projects themselves.  I think it would be great to converge
> them on things like this, but trying to get them all to work the same
> is what led us to openstackclient due to backward compatibility and
> all.  My guess would be that the existing client binaries would live
> through the 'G' release even if we decided to deprecate them now.
>
>> I agree with Dolph - there is a precedent from other well-known
>> programs (git, hg, svn are the first ones I can think of) for --help
>> to behave differently depending on whether or not it was preceded by a
>> subcommand.  So my vote is that we should definitely aim to adhere to
>> this pattern.
>
> How about detailing it in the HIG and once we get a command or two
> implemented with argument parsing we give it a shot?
>
> dt
>
> --
>
> Dean Troyer
> dtro...@gmail.com
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Openstack] OpenStack Client Followup

[Dean Troyer]

On Tue, May 1, 2012 at 2:11 PM, Adam Spiers  wrote:
> As of my recent patch, --help is contextual in nova:

I hadn't seen that yet...

> and I have started work on some of the other commands too, so it would
> be helpful if we could reach a consensus on this soon ... although
> please let me know if I am wasting my time working on other commands
> due to any imminent rewrites using python-openstack!

The continued existence of the project-specific commands is really up
to the projects themselves.  I think it would be great to converge
them on things like this, but trying to get them all to work the same
is what led us to openstackclient due to backward compatibility and
all.  My guess would be that the existing client binaries would live
through the 'G' release even if we decided to deprecate them now.

> I agree with Dolph - there is a precedent from other well-known
> programs (git, hg, svn are the first ones I can think of) for --help
> to behave differently depending on whether or not it was preceded by a
> subcommand.  So my vote is that we should definitely aim to adhere to
> this pattern.

How about detailing it in the HIG and once we get a command or two
implemented with argument parsing we give it a shot?

dt

-- 

Dean Troyer
dtro...@gmail.com

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

Re: [Openstack] OpenStack Client Followup

[Doug Hellmann]

On Tue, May 1, 2012 at 1:54 PM, Adam Spiers  wrote:

> Matt Joyce (m...@nycresistor.com) wrote:
> > >  3. I think it would be good if the HIG recommended that, at least
> > > when subcommands are permitted, single arguments '--help' and
> > > 'help' always generate identical output:
> > >
> > >   https://bugs.launchpad.net/keystone/+bug/936399
> > >   https://review.openstack.org/#/c/6460/
> >
> > Same for Version ( --version )
>
> Good point!  I've added some draft text to the wiki page for that,
> partially pinched from:
>
>
> http://www.gnu.org/prep/standards/standards.html#Command_002dLine-Interfaces
>
> As you can see, the GNU standards go into great detail regarding
> --version; I don't know if we want to be as stringent, particularly
> regarding copyright / license notices, but there's some good food for
> thought there.
>

The version flag is also handled by argparse automatically. We can set the
version string to whatever we want, of course.


>
> > >  5. I think it would be good if the HIG specified what sort of help
> > > text should be included alongside error messages of (say) the
> > > "you didn't give the right number of arguments" variety, and
> > > whether the error message should appear before or after that help
> > > text.  My vote is after, because it's far easier for the human
> > > eye to locate the end of a command's output than the beginning,
> > > especially if the beginning has scrolled off the top of the
> > > terminal.
> >
> > I wonder if this event tracking is relevant to metering.  At the very
> > least it could be relevant to an audit log / revision history.
> >
> > Curious if that's outside the scope of the CLI.   For one, I believe
> > it would be worthwhile to be able to integrate with the APIs to
> > provide a recall of past events and results.
>
> Agreed - while server-side auditing is a more important component than
> client-side, having both sounds potentially useful to me too.  And
> while it's outside the scope of a CLI HIG discussion, it's
> nevertheless relevant to any work on a unified CLI.
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] OpenStack Client Followup

[Adam Spiers]

Dean Troyer (dtro...@gmail.com) wrote:
> On Mon, Apr 30, 2012 at 2:19 PM, Dolph Mathews  
> wrote:
> > I find this behavior really annoying... --help should be contextual
> > (depending on whether a subcommand is present, and what it is).
> 
> > I hope not... +1 for argparse.
> 
> Actually, argparse is one reason for this behaviour.  It doesn't like
> duplicated options in subparsers, nor subsets of names like we found
> in keystone with --tenant and --tenant_id, etc.  IIRC none of the
> existing clients do that, they all rely on 'help command' to get
> command-specific help.

As of my recent patch, --help is contextual in nova:

  https://review.openstack.org/6460

and I have started work on some of the other commands too, so it would
be helpful if we could reach a consensus on this soon ... although
please let me know if I am wasting my time working on other commands
due to any imminent rewrites using python-openstack!

I agree with Dolph - there is a precedent from other well-known
programs (git, hg, svn are the first ones I can think of) for --help
to behave differently depending on whether or not it was preceded by a
subcommand.  So my vote is that we should definitely aim to adhere to
this pattern.

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

Re: [Openstack] OpenStack Client Followup

[Dean Troyer]

On Tue, May 1, 2012 at 12:54 PM, Adam Spiers  wrote:
> Agreed - while server-side auditing is a more important component than
> client-side, having both sounds potentially useful to me too.  And
> while it's outside the scope of a CLI HIG discussion, it's
> nevertheless relevant to any work on a unified CLI.

Sounds like a blueprint waiting to be written... ;)

dt

-- 

Dean Troyer
dtro...@gmail.com

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

Re: [Openstack] OpenStack Client Followup

[Adam Spiers]

Matt Joyce (m...@nycresistor.com) wrote:
> >  3. I think it would be good if the HIG recommended that, at least
> >     when subcommands are permitted, single arguments '--help' and
> >     'help' always generate identical output:
> >
> >       https://bugs.launchpad.net/keystone/+bug/936399
> >       https://review.openstack.org/#/c/6460/
> 
> Same for Version ( --version )

Good point!  I've added some draft text to the wiki page for that,
partially pinched from:

  http://www.gnu.org/prep/standards/standards.html#Command_002dLine-Interfaces

As you can see, the GNU standards go into great detail regarding
--version; I don't know if we want to be as stringent, particularly
regarding copyright / license notices, but there's some good food for
thought there.

> >  5. I think it would be good if the HIG specified what sort of help
> >     text should be included alongside error messages of (say) the
> >     "you didn't give the right number of arguments" variety, and
> >     whether the error message should appear before or after that help
> >     text.  My vote is after, because it's far easier for the human
> >     eye to locate the end of a command's output than the beginning,
> >     especially if the beginning has scrolled off the top of the
> >     terminal.
> 
> I wonder if this event tracking is relevant to metering.  At the very
> least it could be relevant to an audit log / revision history.
> 
> Curious if that's outside the scope of the CLI.   For one, I believe
> it would be worthwhile to be able to integrate with the APIs to
> provide a recall of past events and results.

Agreed - while server-side auditing is a more important component than
client-side, having both sounds potentially useful to me too.  And
while it's outside the scope of a CLI HIG discussion, it's
nevertheless relevant to any work on a unified CLI.

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

Re: [Openstack] OpenStack Client Followup

[Doug Hellmann]

On Mon, Apr 30, 2012 at 3:27 PM, Dean Troyer  wrote:

> On Mon, Apr 30, 2012 at 2:19 PM, Dolph Mathews 
> wrote:
> > I find this behavior really annoying... --help should be contextual
> > (depending on whether a subcommand is present, and what it is).
>
> > I hope not... +1 for argparse.
>
> Actually, argparse is one reason for this behaviour.  It doesn't like
> duplicated options in subparsers, nor subsets of names like we found
> in keystone with --tenant and --tenant_id, etc.  IIRC none of the
> existing clients do that, they all rely on 'help command' to get
> command-specific help.


Duplicated options will be less of an issue with cliff, since the second
level parser isn't instantiated until after the options to the main program
have already been consumed.
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] OpenStack Client Followup

[Dean Troyer]

On Mon, Apr 30, 2012 at 2:19 PM, Dolph Mathews  wrote:
> I find this behavior really annoying... --help should be contextual
> (depending on whether a subcommand is present, and what it is).

> I hope not... +1 for argparse.

Actually, argparse is one reason for this behaviour.  It doesn't like
duplicated options in subparsers, nor subsets of names like we found
in keystone with --tenant and --tenant_id, etc.  IIRC none of the
existing clients do that, they all rely on 'help command' to get
command-specific help.

dt

-- 

Dean Troyer
dtro...@gmail.com

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

Re: [Openstack] OpenStack Client Followup

[Doug Hellmann]

On Mon, Apr 30, 2012 at 3:19 PM, Dolph Mathews wrote:

>
>
> On Mon, Apr 30, 2012 at 1:18 PM, Doug Hellmann <
> doug.hellm...@dreamhost.com> wrote:
>
>>
>>
>> On Mon, Apr 30, 2012 at 12:13 PM, Adam Spiers  wrote:
>>
>>> Dean Troyer (dtro...@gmail.com) wrote:
>>> > One of the first things to do is to find out who is interested in
>>> > contributing to this project.and hopefully coordinating some of the
>>> > work with the other emerging project-specific clients.  Send me an
>>> > email and I'll build a list to get the discussion started.
>>>
>>> Count me in - by 'build a list' do you mean a new mailing list?
>>>
>>> I've read http://wiki.openstack.org/UnifiedCLI/HumanInterfaceGuidelines
>>> (which looks like a great start on the topic!) and made some minor
>>> tweaks.  Should we discuss the FIXMEs you marked here or elsewhere?  I
>>> wanted to make a few suggestions before I forget - can always continue
>>> discussion elsewhere if appropriate:
>>>
>>>  1. Regarding "The subject names are always specified in command in
>>> their singular form.  This is contrary to natural language use."
>>>
>>>   - I didn't understand the second sentence here, but shouldn't the
>>> HIG should allow for scenarios where the verb can operate both on
>>> individual objects and on multiple objects in batch?
>>>
>>
>> I read that as meaning the command to list instances available to a
>> tenant should be "list server" not the more natural "list servers".
>>
>
> I really hope that "list servers" would work.
>

I tend to agree, I was just explaining how I interpreted what was there.


>
>
>>
>> Can you give an example of a command that would work on multiple objects
>> in batch?
>>
>>
>>>
>>> (Grammatical nitpick: if the verb is acting on the noun, then the
>>> HIG should refer to the noun as "object" rather than "subject".)
>>>
>>>  2. I think it would be good if the HIG gave guidelines on how the
>>> command should behave when run with no arguments.
>>>
>>
>> Running a cliff-based app without any arguments enters "interactive" mode
>> (as of 0.4) which gives the user a new prompt and lets them run multiple
>> commands before exiting. This is intended to be used as an optimization for
>> commands to cache authentication credentials and clients and avoid logging
>> in for every sub-command.
>>
>
> One solution for this today is to use keystone's existing "token_get"
> command, and then run subsequent commands with your specified token. So,
> it's basically one request per command, instead of complete auth + request
> per command.
>
> $ keystone token-get
> $ keystone --token=$TOKEN --endpoint=$ENDPOINT tenant-create [...]
>

That sounds sort of like the way ssh-agent works, and I like that as an
optimization, too.


> Since we're using argparse for the subcommands, the default behavior if a
>> command is run without arguments depends on the subcommand. If the
>> subcommand has no required arguments, it will do whatever it is meant to
>> do. If it does require arguments and sees none, argparse prints an error
>> message about whatever is missing (and possibly suggests that the user use
>> --help to get instructions).
>>
>>
>>>
>>>  3. I think it would be good if the HIG recommended that, at least
>>> when subcommands are permitted, single arguments '--help' and
>>> 'help' always generate identical output:
>>>
>>>   https://bugs.launchpad.net/keystone/+bug/936399
>>>   https://review.openstack.org/#/c/6460/
>>
>>
>> The current version of cliff eats the --help option no matter where it
>> appears on the command line, so to get help on a subcommand you always have
>> to use "help" (without the dashes).
>>
>> $ openstack --help
>> $ openstack list server --help
>>
>> both print the help for the "openstack" command, including a list of
>> available subcommands
>>
>>  $ openstack help list server
>>
>> prints the help for the "list server" subcommand of "openstack"
>>
>
> I find this behavior really annoying... --help should be contextual
> (depending on whether a subcommand is present, and what it is).
>

That's how it worked originally. When I got the pull-request from Dean I
assumed it was intended to follow some existing standard.

>From an implementation perspective, it was challenging to use two levels of
argparse parsers to have the --help option applied separately, so I had the
main app using optparse configured to stop at the first positional argument
(value without a "-" at the front). That was a little ugly, since it
depended on a deprecated module. I was not able to find a way to do exactly
the same thing in argparse without adding some of my own logic on top.


>  4. I think it would be good if the HIG gave guidelines on how the
>>> help text should be formatted - in particular that positional
>>> arguments are covered by the help text (e.g. keystone-manage does
>>> not currently give any info on positional arguments required
>>> until you specify too

Re: [Openstack] OpenStack Client Followup

[Dolph Mathews]

On Mon, Apr 30, 2012 at 1:18 PM, Doug Hellmann
wrote:

>
>
> On Mon, Apr 30, 2012 at 12:13 PM, Adam Spiers  wrote:
>
>> Dean Troyer (dtro...@gmail.com) wrote:
>> > One of the first things to do is to find out who is interested in
>> > contributing to this project.and hopefully coordinating some of the
>> > work with the other emerging project-specific clients.  Send me an
>> > email and I'll build a list to get the discussion started.
>>
>> Count me in - by 'build a list' do you mean a new mailing list?
>>
>> I've read http://wiki.openstack.org/UnifiedCLI/HumanInterfaceGuidelines
>> (which looks like a great start on the topic!) and made some minor
>> tweaks.  Should we discuss the FIXMEs you marked here or elsewhere?  I
>> wanted to make a few suggestions before I forget - can always continue
>> discussion elsewhere if appropriate:
>>
>>  1. Regarding "The subject names are always specified in command in
>> their singular form.  This is contrary to natural language use."
>>
>>   - I didn't understand the second sentence here, but shouldn't the
>> HIG should allow for scenarios where the verb can operate both on
>> individual objects and on multiple objects in batch?
>>
>
> I read that as meaning the command to list instances available to a tenant
> should be "list server" not the more natural "list servers".
>

I really hope that "list servers" would work.


>
> Can you give an example of a command that would work on multiple objects
> in batch?
>
>
>>
>> (Grammatical nitpick: if the verb is acting on the noun, then the
>> HIG should refer to the noun as "object" rather than "subject".)
>>
>>  2. I think it would be good if the HIG gave guidelines on how the
>> command should behave when run with no arguments.
>>
>
> Running a cliff-based app without any arguments enters "interactive" mode
> (as of 0.4) which gives the user a new prompt and lets them run multiple
> commands before exiting. This is intended to be used as an optimization for
> commands to cache authentication credentials and clients and avoid logging
> in for every sub-command.
>

One solution for this today is to use keystone's existing "token_get"
command, and then run subsequent commands with your specified token. So,
it's basically one request per command, instead of complete auth + request
per command.

$ keystone token-get
$ keystone --token=$TOKEN --endpoint=$ENDPOINT tenant-create [...]


>
> Since we're using argparse for the subcommands, the default behavior if a
> command is run without arguments depends on the subcommand. If the
> subcommand has no required arguments, it will do whatever it is meant to
> do. If it does require arguments and sees none, argparse prints an error
> message about whatever is missing (and possibly suggests that the user use
> --help to get instructions).
>
>
>>
>>  3. I think it would be good if the HIG recommended that, at least
>> when subcommands are permitted, single arguments '--help' and
>> 'help' always generate identical output:
>>
>>   https://bugs.launchpad.net/keystone/+bug/936399
>>   https://review.openstack.org/#/c/6460/
>
>
> The current version of cliff eats the --help option no matter where it
> appears on the command line, so to get help on a subcommand you always have
> to use "help" (without the dashes).
>
> $ openstack --help
> $ openstack list server --help
>
> both print the help for the "openstack" command, including a list of
> available subcommands
>
> $ openstack help list server
>
> prints the help for the "list server" subcommand of "openstack"
>

I find this behavior really annoying... --help should be contextual
(depending on whether a subcommand is present, and what it is).


>
>

>
>>  4. I think it would be good if the HIG gave guidelines on how the
>> help text should be formatted - in particular that positional
>> arguments are covered by the help text (e.g. keystone-manage does
>> not currently give any info on positional arguments required
>> until you specify too few).
>>
>
> Do we need to specify this beyond saying that all subcommands must use
> argparse for argument parsing (the new framework depends on it anyway, and
> then they are all consistent)?
>

I hope not... +1 for argparse.


>
>
>>
>>  5. I think it would be good if the HIG specified what sort of help
>> text should be included alongside error messages of (say) the
>> "you didn't give the right number of arguments" variety, and
>> whether the error message should appear before or after that help
>> text.  My vote is after, because it's far easier for the human
>> eye to locate the end of a command's output than the beginning,
>> especially if the beginning has scrolled off the top of the
>> terminal.
>
>
>> Thanks,
>> Adam
>>
>> ___
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net
>> Unsubscribe : https://l

Re: [Openstack] OpenStack Client Followup

[Doug Hellmann]

On Mon, Apr 30, 2012 at 2:56 PM, Dean Troyer  wrote:

> On Mon, Apr 30, 2012 at 1:18 PM, Doug Hellmann
>  wrote:
> > Running a cliff-based app without any arguments enters "interactive" mode
> > (as of 0.4) which gives the user a new prompt and lets them run multiple
> > commands before exiting. This is intended to be used as an optimization
> for
> > commands to cache authentication credentials and clients and avoid
> logging
> > in for every sub-command.
>
> Dang dude, let us catch up!
>

I had some spare time this weekend. :-)

FWIW, it's possible (likely) that the pull-request I sent last week that
got "list server" working doesn't work with the latest cliff. I haven't had
a chance to test, yet.


> > Do we need to specify this beyond saying that all subcommands must use
> > argparse for argument parsing (the new framework depends on it anyway,
> and
> > then they are all consistent)?
>
> We should document that, I had just assumed it until now.


Agreed.

Doug
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] OpenStack Client Followup

[Dean Troyer]

On Mon, Apr 30, 2012 at 1:18 PM, Doug Hellmann
 wrote:
> Running a cliff-based app without any arguments enters "interactive" mode
> (as of 0.4) which gives the user a new prompt and lets them run multiple
> commands before exiting. This is intended to be used as an optimization for
> commands to cache authentication credentials and clients and avoid logging
> in for every sub-command.

Dang dude, let us catch up!

> Do we need to specify this beyond saying that all subcommands must use
> argparse for argument parsing (the new framework depends on it anyway, and
> then they are all consistent)?

We should document that, I had just assumed it until now.

dt

-- 

Dean Troyer
dtro...@gmail.com

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

Re: [Openstack] OpenStack Client Followup

[Doug Hellmann]

On Mon, Apr 30, 2012 at 12:13 PM, Adam Spiers  wrote:

> Dean Troyer (dtro...@gmail.com) wrote:
> > One of the first things to do is to find out who is interested in
> > contributing to this project.and hopefully coordinating some of the
> > work with the other emerging project-specific clients.  Send me an
> > email and I'll build a list to get the discussion started.
>
> Count me in - by 'build a list' do you mean a new mailing list?
>
> I've read http://wiki.openstack.org/UnifiedCLI/HumanInterfaceGuidelines
> (which looks like a great start on the topic!) and made some minor
> tweaks.  Should we discuss the FIXMEs you marked here or elsewhere?  I
> wanted to make a few suggestions before I forget - can always continue
> discussion elsewhere if appropriate:
>
>  1. Regarding "The subject names are always specified in command in
> their singular form.  This is contrary to natural language use."
>
>   - I didn't understand the second sentence here, but shouldn't the
> HIG should allow for scenarios where the verb can operate both on
> individual objects and on multiple objects in batch?
>

I read that as meaning the command to list instances available to a tenant
should be "list server" not the more natural "list servers".

Can you give an example of a command that would work on multiple objects in
batch?


>
> (Grammatical nitpick: if the verb is acting on the noun, then the
> HIG should refer to the noun as "object" rather than "subject".)
>
>  2. I think it would be good if the HIG gave guidelines on how the
> command should behave when run with no arguments.
>

Running a cliff-based app without any arguments enters "interactive" mode
(as of 0.4) which gives the user a new prompt and lets them run multiple
commands before exiting. This is intended to be used as an optimization for
commands to cache authentication credentials and clients and avoid logging
in for every sub-command.

Since we're using argparse for the subcommands, the default behavior if a
command is run without arguments depends on the subcommand. If the
subcommand has no required arguments, it will do whatever it is meant to
do. If it does require arguments and sees none, argparse prints an error
message about whatever is missing (and possibly suggests that the user use
--help to get instructions).


>
>  3. I think it would be good if the HIG recommended that, at least
> when subcommands are permitted, single arguments '--help' and
> 'help' always generate identical output:
>
>   https://bugs.launchpad.net/keystone/+bug/936399
>   https://review.openstack.org/#/c/6460/


The current version of cliff eats the --help option no matter where it
appears on the command line, so to get help on a subcommand you always have
to use "help" (without the dashes).

$ openstack --help
$ openstack list server --help

both print the help for the "openstack" command, including a list of
available subcommands

$ openstack help list server

prints the help for the "list server" subcommand of "openstack"


>  4. I think it would be good if the HIG gave guidelines on how the
> help text should be formatted - in particular that positional
> arguments are covered by the help text (e.g. keystone-manage does
> not currently give any info on positional arguments required
> until you specify too few).
>

Do we need to specify this beyond saying that all subcommands must use
argparse for argument parsing (the new framework depends on it anyway, and
then they are all consistent)?


>
>  5. I think it would be good if the HIG specified what sort of help
> text should be included alongside error messages of (say) the
> "you didn't give the right number of arguments" variety, and
> whether the error message should appear before or after that help
> text.  My vote is after, because it's far easier for the human
> eye to locate the end of a command's output than the beginning,
> especially if the beginning has scrolled off the top of the
> terminal.


> Thanks,
> Adam
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] OpenStack Client Followup

[Matt Joyce]

>
>  2. I think it would be good if the HIG gave guidelines on how the
>     command should behave when run with no arguments.

I think the marines call this sort of thing, Task Condition and
Standard.  Not sure how useful it would be.

>  3. I think it would be good if the HIG recommended that, at least
>     when subcommands are permitted, single arguments '--help' and
>     'help' always generate identical output:
>
>       https://bugs.launchpad.net/keystone/+bug/936399
>       https://review.openstack.org/#/c/6460/

Same for Version ( --version )

>  5. I think it would be good if the HIG specified what sort of help
>     text should be included alongside error messages of (say) the
>     "you didn't give the right number of arguments" variety, and
>     whether the error message should appear before or after that help
>     text.  My vote is after, because it's far easier for the human
>     eye to locate the end of a command's output than the beginning,
>     especially if the beginning has scrolled off the top of the
>     terminal.

I wonder if this event tracking is relevant to metering.  At the very
least it could be relevant to an audit log / revision history.

Curious if that's outside the scope of the CLI.   For one, I believe
it would be worthwhile to be able to integrate with the APIs to
provide a recall of past events and results.

-Matt

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

Re: [Openstack] OpenStack Client Followup

[Adam Spiers]

Dean Troyer (dtro...@gmail.com) wrote:
> One of the first things to do is to find out who is interested in
> contributing to this project.and hopefully coordinating some of the
> work with the other emerging project-specific clients.  Send me an
> email and I'll build a list to get the discussion started.

Count me in - by 'build a list' do you mean a new mailing list?  

I've read http://wiki.openstack.org/UnifiedCLI/HumanInterfaceGuidelines
(which looks like a great start on the topic!) and made some minor
tweaks.  Should we discuss the FIXMEs you marked here or elsewhere?  I
wanted to make a few suggestions before I forget - can always continue
discussion elsewhere if appropriate:

  1. Regarding "The subject names are always specified in command in
 their singular form.  This is contrary to natural language use."

   - I didn't understand the second sentence here, but shouldn't the
 HIG should allow for scenarios where the verb can operate both on
 individual objects and on multiple objects in batch?

 (Grammatical nitpick: if the verb is acting on the noun, then the
 HIG should refer to the noun as "object" rather than "subject".)

  2. I think it would be good if the HIG gave guidelines on how the
 command should behave when run with no arguments.

  3. I think it would be good if the HIG recommended that, at least
 when subcommands are permitted, single arguments '--help' and
 'help' always generate identical output:

   https://bugs.launchpad.net/keystone/+bug/936399
   https://review.openstack.org/#/c/6460/

  4. I think it would be good if the HIG gave guidelines on how the
 help text should be formatted - in particular that positional
 arguments are covered by the help text (e.g. keystone-manage does
 not currently give any info on positional arguments required
 until you specify too few).

  5. I think it would be good if the HIG specified what sort of help
 text should be included alongside error messages of (say) the
 "you didn't give the right number of arguments" variety, and
 whether the error message should appear before or after that help
 text.  My vote is after, because it's far easier for the human
 eye to locate the end of a command's output than the beginning,
 especially if the beginning has scrolled off the top of the
 terminal.

Thanks,
Adam

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

Re: [Openstack] OpenStack Client Followup

[Adam Spiers]

Dean Troyer (dtro...@gmail.com) wrote:
> We had a good discussion about a unified OpenStack command line client
> on Monday at the Design Summit.  The notes are in the Etherpad at
> http://etherpad.openstack.org/FolsumCLI, I summarized my recollection
> at the bottom; those who were there feel free to add the bits I
> missed.
> 
> One of the first things to do is to find out who is interested in
> contributing to this project.and hopefully coordinating some of the
> work with the other emerging project-specific clients.  Send me an
> email and I'll build a list to get the discussion started.

I missed the session but I'm interested in this and should be able to
contribute a few opinions at the very least, and hopefully some
commits too (I'm already working on unifying help output across
various commands).

> We also should look for some consensus on the name of the command
> itself.  'oscli' is a placeholder, and while sufficiently short and
> unique for my tastes it is hard to pronounce and remember.  The
> leading candidates I have heard at the summit so far are 'openstack'
> and 'stack'.  Let's gather some feedback at the bottom of the Etherpad
> about this as I am sure there are other opinions out there.

I have added my votes, tidied up the voting text in the etherpad (it
was a little unclear which were total vote counts vs. individual
votes), and suggested another possibility: 'ost', although FWIW I
prefer 'openstack' which is unambiguous, obvious, and unforgettable.
Bearing in mind Murphy's Law, whatever 3- or 4-letter abbreviation you
choose, there's a chance it's already been claimed for some other
purpose in at least one environment somewhere :-)  For example, in an
Ubuntu world, someone might really like 'osc' because it's fast to
type and fairly easy to remember ("OpenStack CLI") ... but in a SUSE
world, that would be full of fail because osc is already heavily used
as the CLI for the Open Build Service.  So keeping it as 'openstack'
would allow Ubuntu folk (in this example) to do 'alias osc=openstack'
and SUSE folk to do (say) 'alias ost=openstack'.

Thanks!
Adam

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

Re: [Openstack] OpenStack Client Followup

[Lorin Hochstein]

I'm interested as well. 

I wasn't able to attend the session, but I'd like to see something akin to the 
proposed Human Interface Guideline    for the 
CLI to ensure that the implementation achieves the goals spelled out in the 
Etherpad.

Take care,

Lorin
--
Lorin Hochstein
Lead Architect - Cloud Services
Nimbis Services, Inc.
www.nimbisservices.com





On Apr 19, 2012, at 1:57 PM, Matt Joyce wrote:

> I'd be down with helping out as well.
> 
> On Thu, Apr 19, 2012 at 1:43 PM, Doug Hellmann
>  wrote:
>> 
>> 
>> On Wed, Apr 18, 2012 at 11:07 PM, Dean Troyer  wrote:
>>> 
>>> We had a good discussion about a unified OpenStack command line client
>>> on Monday at the Design Summit.  The notes are in the Etherpad at
>>> http://etherpad.openstack.org/FolsumCLI, I summarized my recollection
>>> at the bottom; those who were there feel free to add the bits I
>>> missed.
>>> 
>>> One of the first things to do is to find out who is interested in
>>> contributing to this project.and hopefully coordinating some of the
>>> work with the other emerging project-specific clients.  Send me an
>>> email and I'll build a list to get the discussion started.
>> 
>> 
>> Count me in.
>> 
>>> 
>>> 
>>> We also should look for some consensus on the name of the command
>>> itself.  'oscli' is a placeholder, and while sufficiently short and
>>> unique for my tastes it is hard to pronounce and remember.  The
>>> leading candidates I have heard at the summit so far are 'openstack'
>>> and 'stack'.  Let's gather some feedback at the bottom of the Etherpad
>>> about this as I am sure there are other opinions out there.
>>> 
>>> Thanks
>>> dt
>>> 
>>> --
>>> 
>>> Dean Troyer
>>> dtro...@gmail.com
>>> 
>>> ___
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to : openstack@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>> 
>> 
>> 
>> ___
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>> 
> 
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Openstack] OpenStack Client Followup

[Matt Joyce]

I'd be down with helping out as well.

On Thu, Apr 19, 2012 at 1:43 PM, Doug Hellmann
 wrote:
>
>
> On Wed, Apr 18, 2012 at 11:07 PM, Dean Troyer  wrote:
>>
>> We had a good discussion about a unified OpenStack command line client
>> on Monday at the Design Summit.  The notes are in the Etherpad at
>> http://etherpad.openstack.org/FolsumCLI, I summarized my recollection
>> at the bottom; those who were there feel free to add the bits I
>> missed.
>>
>> One of the first things to do is to find out who is interested in
>> contributing to this project.and hopefully coordinating some of the
>> work with the other emerging project-specific clients.  Send me an
>> email and I'll build a list to get the discussion started.
>
>
> Count me in.
>
>>
>>
>> We also should look for some consensus on the name of the command
>> itself.  'oscli' is a placeholder, and while sufficiently short and
>> unique for my tastes it is hard to pronounce and remember.  The
>> leading candidates I have heard at the summit so far are 'openstack'
>> and 'stack'.  Let's gather some feedback at the bottom of the Etherpad
>> about this as I am sure there are other opinions out there.
>>
>> Thanks
>> dt
>>
>> --
>>
>> Dean Troyer
>> dtro...@gmail.com
>>
>> ___
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>

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

Re: [Openstack] OpenStack Client Followup

[Doug Hellmann]

On Wed, Apr 18, 2012 at 11:07 PM, Dean Troyer  wrote:

> We had a good discussion about a unified OpenStack command line client
> on Monday at the Design Summit.  The notes are in the Etherpad at
> http://etherpad.openstack.org/FolsumCLI, I summarized my recollection
> at the bottom; those who were there feel free to add the bits I
> missed.
>
> One of the first things to do is to find out who is interested in
> contributing to this project.and hopefully coordinating some of the
> work with the other emerging project-specific clients.  Send me an
> email and I'll build a list to get the discussion started.
>

Count me in.


>
> We also should look for some consensus on the name of the command
> itself.  'oscli' is a placeholder, and while sufficiently short and
> unique for my tastes it is hard to pronounce and remember.  The
> leading candidates I have heard at the summit so far are 'openstack'
> and 'stack'.  Let's gather some feedback at the bottom of the Etherpad
> about this as I am sure there are other opinions out there.
>
> Thanks
> dt
>
> --
>
> Dean Troyer
> dtro...@gmail.com
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] OpenStack Client Followup

[Matt Joyce]

Reminds me of the Opsware Global Shell.  That was built on a FUSE fs
interface to the API.  I loved it when I worked on it.

-Matt

On Wed, Apr 18, 2012 at 11:07 PM, Dean Troyer  wrote:
> We had a good discussion about a unified OpenStack command line client
> on Monday at the Design Summit.  The notes are in the Etherpad at
> http://etherpad.openstack.org/FolsumCLI, I summarized my recollection
> at the bottom; those who were there feel free to add the bits I
> missed.
>
> One of the first things to do is to find out who is interested in
> contributing to this project.and hopefully coordinating some of the
> work with the other emerging project-specific clients.  Send me an
> email and I'll build a list to get the discussion started.
>
> We also should look for some consensus on the name of the command
> itself.  'oscli' is a placeholder, and while sufficiently short and
> unique for my tastes it is hard to pronounce and remember.  The
> leading candidates I have heard at the summit so far are 'openstack'
> and 'stack'.  Let's gather some feedback at the bottom of the Etherpad
> about this as I am sure there are other opinions out there.
>
> Thanks
> dt
>
> --
>
> Dean Troyer
> dtro...@gmail.com
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

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