openstack team mailing list archive

[Doug Hellmann <doug.hellmann@xxxxxxxxxxxxx>]

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
>