On Wed, May 2, 2012 at 1:56 PM, Matt Joyce <m...@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 <dun...@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.math...@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.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 <m...@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 <dtro...@gmail.com> wrote:
>>>>> > On Tue, May 1, 2012 at 2:11 PM, Adam Spiers <aspi...@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
>>>>> > 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
>>>
>> _______________________________________________
>> Openstack-operators mailing list
>> openstack-operat...@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
