openstack team mailing list archive

[Joshua Harlow <harlowja@xxxxxxxxxxxxx>]

I like #1, if the admin plugins aren't there then u don't get admin commands. Plus it makes a lot of the same code be used in both cases.


On 5/1/12 4: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