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.hellm...@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 <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
