<div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 2, 2012 at 2:46 PM, Duncan McGreggor <span dir="ltr"><<a href="mailto:duncan@dreamhost.com" target="_blank">duncan@dreamhost.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Wed, May 2, 2012 at 1:56 PM, Matt Joyce <<a href="mailto:matt@nycresistor.com">matt@nycresistor.com</a>> wrote:<br>
> I disagree pretty strongly with the idea of an admin binary.<br>
<br>
</div>I think many of us do; I (and I believe Doug) were simply preferring<br>
1) a single binary with 2) division of commands.<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> Fundamentally my consternation with the idea comes from what I see as<br>
> such a clear and final delineation in what I expect will be a very<br>
> complex ACL set in the future. I can't see there being something as<br>
> simple as an admin and a user in any orchestration environment. There<br>
> will be more roles than that.<br>
<br>
</div>Agreed.<br>
<div class="im"><br>
> The client shouldn't be making any presumptions when it comes to ACLs.<br>
<br>
</div>Agreed.<br>
<div class="im"><br>
> We shouldn't be drawing lines in the sand. And I guess more to the<br>
> point we shouldn't be solving problems we don't have. For now I would<br>
> be happy to just throw a "permission denied" when it happens. We can<br>
> solve the problem when it becomes defined ( later ). Creating a whole<br>
> second binary seems like a nuclear solution to a problem we don't even<br>
> really have.<br>
<br>
</div>So, I think if you re-read my email, you'll see that we're essentially<br>
of the same view.<br>
<br>
1) I don't think a separate binary is a good idea<br>
2) I don't think we should solve problems before we have data on them<br>
<br>
but in addition,<br>
<br>
3) I think we should anticipate a future need of defining things such as ACLs.<br>
<br>
Organizing the CLI's commands via a subcommand like Doug proposed<br>
could be part of a solution like that. I doesn't have to be, but it<br>
could be. Making sure that we don't limit our options in the future<br>
would be a good thing :-)<br>
<span class="HOEnZb"><font color="#888888"><br>
d<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> The APIs are handling the permission checks after all.<br>
><br>
> -Matt<br>
><br>
> On Wed, May 2, 2012 at 10:32 AM, Duncan McGreggor <<a href="mailto:duncan@dreamhost.com">duncan@dreamhost.com</a>> wrote:<br>
>> You make some fair points.<br>
>><br>
>> But consider the large class of cloud users that will never need to<br>
>> bring up OpenStack from scratch, but rather maintain them. These users<br>
>> will need to be able to easily identify the commands that pertain to<br>
>> their daily maintenance, troubleshooting, and reporting tasks. Design<br>
>> of a CLI tool for different audiences is just as important as visual<br>
>> interface design.<br>
>><br>
>> However, anticipating that now, before we have solid usage data, may<br>
>> be premature.<br>
>><br>
>> In order to eventually deliver improved organization of CLI commands<br>
>> and a good usability experience for all classes of users, I'd ask that<br>
>> we at least leave room in the design of these tools such that<br>
>> improving the command organization later will be a trivial task.<br>
>><br>
>> d<br>
>><br>
>> On Wed, May 2, 2012 at 9:14 AM, Dolph Mathews <<a href="mailto:dolph.mathews@gmail.com">dolph.mathews@gmail.com</a>> wrote:<br>
>>> I disagree with all three... the line between "admin" and "not admin" is<br>
>>> going to get very blurry in the long run. Example: I may be a regular user,<br>
>>> but I've been granted what is "normally" an admin capability on tenant X.<br>
>>> Does that make me an admin? Do I now need to use two different clients?<br>
>>><br>
>>> I also don't think it should be the client's *responsibility* to understand<br>
>>> what capabilities are required for any given command (ultimately making<br>
>>> *assumptions* about what the service will allow the user to do), as it's the<br>
>>> remote service that's ultimately going to enforce it's own policies. It may<br>
>>> be a decent feature to warn the user something is probably not going to work<br>
>>> (or better yet, the ability to ask the remote service if something will<br>
>>> succeed before we attempt it), but the client shouldn't prevent the user<br>
>>> from trying -- especially by suppressing/isolating features. Horizon is<br>
>>> going to face the same challenge (hiding/showing capability-relevant UI).<br>
>>><br>
>>> tl;dr: openstackclient should be uniformly featured across all OpenStack<br>
>>> API's ("service", "admin" or otherwise)<br>
>>><br>
>>> -Dolph<br>
>>><br>
>>> On Tue, May 1, 2012 at 6:55 PM, Doug Hellmann <<a href="mailto:doug.hellmann@dreamhost.com">doug.hellmann@dreamhost.com</a>><br>
>>> wrote:<br>
>>>><br>
>>>> There are a couple of ways to handle that:<br>
>>>><br>
>>>> 1. A separate "openstackadmin" CLI that looks for commands using a<br>
>>>> different plugin namespace, and therefore only loads the admin commands.<br>
>>>><br>
>>>> 2. Prefix admin-related commands in the unified cli with "admin" (so<br>
>>>> "openstack admin create network" or whatever).<br>
>>>><br>
>>>> 3. Separate admin apps for each project.<br>
>>>><br>
>>>> I think we should avoid 3, since that goes against the spirit of this<br>
>>>> project. I like #2, but #1 would be easy to implement and could share 99% of<br>
>>>> the code from the basic openstackclient.<br>
>>>><br>
>>>> On Tue, May 1, 2012 at 4:59 PM, Matt Joyce <<a href="mailto:matt@nycresistor.com">matt@nycresistor.com</a>> wrote:<br>
>>>>><br>
>>>>> How does this blueprint play into this client. Is it a separate admin<br>
>>>>> only client or just a subset of this guy?<br>
>>>>><br>
>>>>> <a href="https://blueprints.launchpad.net/nova/+spec/admin-cli" target="_blank">https://blueprints.launchpad.net/nova/+spec/admin-cli</a><br>
>>>>><br>
>>>>> -matt<br>
>>>>><br>
>>>>> On Tue, May 1, 2012 at 12:28 PM, Dean Troyer <<a href="mailto:dtroyer@gmail.com">dtroyer@gmail.com</a>> wrote:<br>
>>>>> > On Tue, May 1, 2012 at 2:11 PM, Adam Spiers <<a href="mailto:aspiers@suse.com">aspiers@suse.com</a>> wrote:<br>
>>>>> >> As of my recent patch, --help is contextual in nova:<br>
>>>>> ><br>
>>>>> > I hadn't seen that yet...<br>
>>>>> ><br>
>>>>> >> and I have started work on some of the other commands too, so it would<br>
>>>>> >> be helpful if we could reach a consensus on this soon ... although<br>
>>>>> >> please let me know if I am wasting my time working on other commands<br>
>>>>> >> due to any imminent rewrites using python-openstack!<br>
>>>>> ><br>
>>>>> > The continued existence of the project-specific commands is really up<br>
>>>>> > to the projects themselves. I think it would be great to converge<br>
>>>>> > them on things like this, but trying to get them all to work the same<br>
>>>>> > is what led us to openstackclient due to backward compatibility and<br>
>>>>> > all. My guess would be that the existing client binaries would live<br>
>>>>> > through the 'G' release even if we decided to deprecate them now.<br>
>>>>> ><br>
>>>>> >> I agree with Dolph - there is a precedent from other well-known<br>
>>>>> >> programs (git, hg, svn are the first ones I can think of) for --help<br>
>>>>> >> to behave differently depending on whether or not it was preceded by a<br>
>>>>> >> subcommand. So my vote is that we should definitely aim to adhere to<br>
>>>>> >> this pattern.<br>
>>>>> ><br>
>>>>> > How about detailing it in the HIG and once we get a command or two<br>
>>>>> > implemented with argument parsing we give it a shot?<br>
>>>>> ><br>
>>>>> > dt<br>
>>>>> ><br>
>>>>> > --<br>
>>>>> ><br>
>>>>> > Dean Troyer<br>
>>>>> > <a href="mailto:dtroyer@gmail.com">dtroyer@gmail.com</a><br>
>>>>> ><br>
>>>>> > _______________________________________________<br>
>>>>> > Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
>>>>> > Post to : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
>>>>> > Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
>>>>> > More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
>>>>><br>
>>>>> _______________________________________________<br>
>>>>> Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
>>>>> Post to : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
>>>>> Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
>>>>> More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
>>>><br>
>>>><br>
>>>><br>
>>>> _______________________________________________<br>
>>>> Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
>>>> Post to : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
>>>> Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
>>>> More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
>>>><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
>>> Post to : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
>>> Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
>>> More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
>>><br>
>> _______________________________________________<br>
>> Openstack-operators mailing list<br>
>> <a href="mailto:Openstack-operators@lists.openstack.org">Openstack-operators@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
_______________________________________________<br>
Openstack-operators mailing list<br>
<a href="mailto:Openstack-operators@lists.openstack.org">Openstack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</div></div></blockquote></div><br></div>