openstack team mailing list archive

[Matt Joyce <matt@xxxxxxxxxxxxxxx>]

Good to have options.

On Wed, May 2, 2012 at 11:46 AM, Duncan McGreggor <duncan@xxxxxxxxxxxxx> wrote:
> On Wed, May 2, 2012 at 1:56 PM, Matt Joyce <matt@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxxxxx>
>>>> 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@xxxxxxxxxxxxxxx> 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@xxxxxxxxx> wrote:
>>>>>> > On Tue, May 1, 2012 at 2:11 PM, Adam Spiers <aspiers@xxxxxxxx> 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@xxxxxxxxx
>>>>>> >
>>>>>> > _______________________________________________
>>>>>> > Mailing list: https://launchpad.net/~openstack
>>>>>> > Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>>>>>> > Unsubscribe : https://launchpad.net/~openstack
>>>>>> > More help   : https://help.launchpad.net/ListHelp
>>>>>>
>>>>>> _______________________________________________
>>>>>> Mailing list: https://launchpad.net/~openstack
>>>>>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>>>>>> Unsubscribe : https://launchpad.net/~openstack
>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Mailing list: https://launchpad.net/~openstack
>>>>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>>>>> Unsubscribe : https://launchpad.net/~openstack
>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~openstack
>>>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>>>> Unsubscribe : https://launchpad.net/~openstack
>>>> More help   : https://help.launchpad.net/ListHelp
>>>>
>>> _______________________________________________
>>> Openstack-operators mailing list
>>> Openstack-operators@xxxxxxxxxxxxxxxxxxx
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators