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