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