Open Stack

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
<doug.hellmann at 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 at 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 at gmail.com> wrote:
>> > On Tue, May 1, 2012 at 2:11 PM, Adam Spiers <aspiers at 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 at gmail.com
>> >
>> > _______________________________________________
>> > Mailing list: https://launchpad.net/~openstack
>> > Post to     : openstack at lists.launchpad.net
>> > Unsubscribe : https://launchpad.net/~openstack
>> > More help   : https://help.launchpad.net/ListHelp
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack at lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>
>