Mailing List Archive

Re: [Openstack] OpenStack Client Followup
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 <dolph.mathews@gmail.com> 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.hellmann@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 <matt@nycresistor.com> 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 <dtroyer@gmail.com> wrote:
>>> > On Tue, May 1, 2012 at 2:11 PM, Adam Spiers <aspiers@suse.com> 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
>>> > dtroyer@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
>
_______________________________________________
Openstack-operators mailing list
Openstack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack] OpenStack Client Followup [ In reply to ]
I disagree pretty strongly with the idea of an admin binary.
Fundamentally my consternation with the idea comes from what I see as
such a clear and final delineation in what I expect will be a very
complex ACL set in the future. I can't see there being something as
simple as an admin and a user in any orchestration environment. There
will be more roles than that.

The client shouldn't be making any presumptions when it comes to ACLs.
We shouldn't be drawing lines in the sand. And I guess more to the
point we shouldn't be solving problems we don't have. For now I would
be happy to just throw a "permission denied" when it happens. We can
solve the problem when it becomes defined ( later ). Creating a whole
second binary seems like a nuclear solution to a problem we don't even
really have. The APIs are handling the permission checks after all.

-Matt

On Wed, May 2, 2012 at 10:32 AM, Duncan McGreggor <duncan@dreamhost.com> wrote:
> 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 <dolph.mathews@gmail.com> 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.hellmann@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 <matt@nycresistor.com> 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 <dtroyer@gmail.com> wrote:
>>>> > On Tue, May 1, 2012 at 2:11 PM, Adam Spiers <aspiers@suse.com> 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
>>>> > dtroyer@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
>>
> _______________________________________________
> Openstack-operators mailing list
> Openstack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
_______________________________________________
Openstack-operators mailing list
Openstack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack] OpenStack Client Followup [ In reply to ]
On Wed, May 2, 2012 at 1:56 PM, Matt Joyce <matt@nycresistor.com> wrote:
> I disagree pretty strongly with the idea of an admin binary.

I think many of us do; I (and I believe Doug) were simply preferring
1) a single binary with 2) division of commands.

> Fundamentally my consternation with the idea comes from what I see as
> such a clear and final delineation in what I expect will be a very
> complex ACL set in the future.  I can't see there being something as
> simple as an admin and a user in any orchestration environment.  There
> will be more roles than that.

Agreed.

> The client shouldn't be making any presumptions when it comes to ACLs.

Agreed.

>  We shouldn't be drawing lines in the sand.  And I guess more to the
> point we shouldn't be solving problems we don't have.  For now I would
> be happy to just throw a "permission denied" when it happens.  We can
> solve the problem when it becomes defined ( later ).  Creating a whole
> second binary seems like a nuclear solution to a problem we don't even
> really have.

So, I think if you re-read my email, you'll see that we're essentially
of the same view.

1) I don't think a separate binary is a good idea
2) I don't think we should solve problems before we have data on them

but in addition,

3) I think we should anticipate a future need of defining things such as ACLs.

Organizing the CLI's commands via a subcommand like Doug proposed
could be part of a solution like that. I doesn't have to be, but it
could be. Making sure that we don't limit our options in the future
would be a good thing :-)

d

> The APIs are handling the permission checks after all.
>
> -Matt
>
> On Wed, May 2, 2012 at 10:32 AM, Duncan McGreggor <duncan@dreamhost.com> wrote:
>> 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 <dolph.mathews@gmail.com> 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.hellmann@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 <matt@nycresistor.com> 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 <dtroyer@gmail.com> wrote:
>>>>> > On Tue, May 1, 2012 at 2:11 PM, Adam Spiers <aspiers@suse.com> 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
>>>>> > dtroyer@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
>>>
>> _______________________________________________
>> Openstack-operators mailing list
>> Openstack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
_______________________________________________
Openstack-operators mailing list
Openstack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack] OpenStack Client Followup [ In reply to ]
Good to have options.

On Wed, May 2, 2012 at 11:46 AM, Duncan McGreggor <duncan@dreamhost.com> wrote:
> On Wed, May 2, 2012 at 1:56 PM, Matt Joyce <matt@nycresistor.com> wrote:
>> I disagree pretty strongly with the idea of an admin binary.
>
> I think many of us do; I (and I believe Doug) were simply preferring
> 1) a single binary with 2) division of commands.
>
>> Fundamentally my consternation with the idea comes from what I see as
>> such a clear and final delineation in what I expect will be a very
>> complex ACL set in the future.  I can't see there being something as
>> simple as an admin and a user in any orchestration environment.  There
>> will be more roles than that.
>
> Agreed.
>
>> The client shouldn't be making any presumptions when it comes to ACLs.
>
> Agreed.
>
>>  We shouldn't be drawing lines in the sand.  And I guess more to the
>> point we shouldn't be solving problems we don't have.  For now I would
>> be happy to just throw a "permission denied" when it happens.  We can
>> solve the problem when it becomes defined ( later ).  Creating a whole
>> second binary seems like a nuclear solution to a problem we don't even
>> really have.
>
> So, I think if you re-read my email, you'll see that we're essentially
> of the same view.
>
> 1) I don't think a separate binary is a good idea
> 2) I don't think we should solve problems before we have data on them
>
> but in addition,
>
> 3) I think we should anticipate a future need of defining things such as ACLs.
>
> Organizing the CLI's commands via a subcommand like Doug proposed
> could be part of a solution like that. I doesn't have to be, but it
> could be. Making sure that we don't limit our options in the future
> would be a good thing :-)
>
> d
>
>> The APIs are handling the permission checks after all.
>>
>> -Matt
>>
>> On Wed, May 2, 2012 at 10:32 AM, Duncan McGreggor <duncan@dreamhost.com> wrote:
>>> 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 <dolph.mathews@gmail.com> 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.hellmann@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 <matt@nycresistor.com> 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 <dtroyer@gmail.com> wrote:
>>>>>> > On Tue, May 1, 2012 at 2:11 PM, Adam Spiers <aspiers@suse.com> 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
>>>>>> > dtroyer@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
>>>>
>>> _______________________________________________
>>> Openstack-operators mailing list
>>> Openstack-operators@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
_______________________________________________
Openstack-operators mailing list
Openstack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack] OpenStack Client Followup [ In reply to ]
On Wed, May 2, 2012 at 2:46 PM, Duncan McGreggor <duncan@dreamhost.com>wrote:

> On Wed, May 2, 2012 at 1:56 PM, Matt Joyce <matt@nycresistor.com> wrote:
> > I disagree pretty strongly with the idea of an admin binary.
>
> I think many of us do; I (and I believe Doug) were simply preferring
> 1) a single binary with 2) division of commands.
>

Right. The "admin" commands don't need to be packaged with the CLI app in
order for it to find them and allow a user to use them. The whole point of
the architecture of cliff is to make it easy to add commands from other
packages.


>
> > Fundamentally my consternation with the idea comes from what I see as
> > such a clear and final delineation in what I expect will be a very
> > complex ACL set in the future. I can't see there being something as
> > simple as an admin and a user in any orchestration environment. There
> > will be more roles than that.
>
> Agreed.
>
> > The client shouldn't be making any presumptions when it comes to ACLs.
>
> Agreed.
>
> > We shouldn't be drawing lines in the sand. And I guess more to the
> > point we shouldn't be solving problems we don't have. For now I would
> > be happy to just throw a "permission denied" when it happens. We can
> > solve the problem when it becomes defined ( later ). Creating a whole
> > second binary seems like a nuclear solution to a problem we don't even
> > really have.
>
> So, I think if you re-read my email, you'll see that we're essentially
> of the same view.
>
> 1) I don't think a separate binary is a good idea
> 2) I don't think we should solve problems before we have data on them
>
> but in addition,
>
> 3) I think we should anticipate a future need of defining things such as
> ACLs.
>
> Organizing the CLI's commands via a subcommand like Doug proposed
> could be part of a solution like that. I doesn't have to be, but it
> could be. Making sure that we don't limit our options in the future
> would be a good thing :-)
>
> d
>
> > The APIs are handling the permission checks after all.
> >
> > -Matt
> >
> > On Wed, May 2, 2012 at 10:32 AM, Duncan McGreggor <duncan@dreamhost.com>
> wrote:
> >> 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 <dolph.mathews@gmail.com>
> 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.hellmann@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 <matt@nycresistor.com>
> 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 <dtroyer@gmail.com>
> wrote:
> >>>>> > On Tue, May 1, 2012 at 2:11 PM, Adam Spiers <aspiers@suse.com>
> 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
> >>>>> > dtroyer@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
> >>>
> >> _______________________________________________
> >> Openstack-operators mailing list
> >> Openstack-operators@lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> _______________________________________________
> Openstack-operators mailing list
> Openstack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>