On Wed, May 2, 2012 at 2:46 PM, Duncan McGreggor <dun...@dreamhost.com>wrote:
> On Wed, May 2, 2012 at 1:56 PM, Matt Joyce <m...@nycresistor.com> wrote: > > I disagree pretty strongly with the idea of an admin binary. > > I think many of us do; I (and I believe Doug) were simply preferring > 1) a single binary with 2) division of commands. > Right. The "admin" commands don't need to be packaged with the CLI app in order for it to find them and allow a user to use them. The whole point of the architecture of cliff is to make it easy to add commands from other packages. > > > Fundamentally my consternation with the idea comes from what I see as > > such a clear and final delineation in what I expect will be a very > > complex ACL set in the future. I can't see there being something as > > simple as an admin and a user in any orchestration environment. There > > will be more roles than that. > > Agreed. > > > The client shouldn't be making any presumptions when it comes to ACLs. > > Agreed. > > > We shouldn't be drawing lines in the sand. And I guess more to the > > point we shouldn't be solving problems we don't have. For now I would > > be happy to just throw a "permission denied" when it happens. We can > > solve the problem when it becomes defined ( later ). Creating a whole > > second binary seems like a nuclear solution to a problem we don't even > > really have. > > So, I think if you re-read my email, you'll see that we're essentially > of the same view. > > 1) I don't think a separate binary is a good idea > 2) I don't think we should solve problems before we have data on them > > but in addition, > > 3) I think we should anticipate a future need of defining things such as > ACLs. > > Organizing the CLI's commands via a subcommand like Doug proposed > could be part of a solution like that. I doesn't have to be, but it > could be. Making sure that we don't limit our options in the future > would be a good thing :-) > > d > > > The APIs are handling the permission checks after all. > > > > -Matt > > > > On Wed, May 2, 2012 at 10:32 AM, Duncan McGreggor <dun...@dreamhost.com> > wrote: > >> You make some fair points. > >> > >> But consider the large class of cloud users that will never need to > >> bring up OpenStack from scratch, but rather maintain them. These users > >> will need to be able to easily identify the commands that pertain to > >> their daily maintenance, troubleshooting, and reporting tasks. Design > >> of a CLI tool for different audiences is just as important as visual > >> interface design. > >> > >> However, anticipating that now, before we have solid usage data, may > >> be premature. > >> > >> In order to eventually deliver improved organization of CLI commands > >> and a good usability experience for all classes of users, I'd ask that > >> we at least leave room in the design of these tools such that > >> improving the command organization later will be a trivial task. > >> > >> d > >> > >> On Wed, May 2, 2012 at 9:14 AM, Dolph Mathews <dolph.math...@gmail.com> > wrote: > >>> I disagree with all three... the line between "admin" and "not admin" > is > >>> going to get very blurry in the long run. Example: I may be a regular > user, > >>> but I've been granted what is "normally" an admin capability on tenant > X. > >>> Does that make me an admin? Do I now need to use two different clients? > >>> > >>> I also don't think it should be the client's *responsibility* to > understand > >>> what capabilities are required for any given command (ultimately making > >>> *assumptions* about what the service will allow the user to do), as > it's the > >>> remote service that's ultimately going to enforce it's own policies. > It may > >>> be a decent feature to warn the user something is probably not going > to work > >>> (or better yet, the ability to ask the remote service if something will > >>> succeed before we attempt it), but the client shouldn't prevent the > user > >>> from trying -- especially by suppressing/isolating features. Horizon is > >>> going to face the same challenge (hiding/showing capability-relevant > UI). > >>> > >>> tl;dr: openstackclient should be uniformly featured across all > OpenStack > >>> API's ("service", "admin" or otherwise) > >>> > >>> -Dolph > >>> > >>> On Tue, May 1, 2012 at 6: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 > >>>> > >>> > >>> > >>> _______________________________________________ > >>> Mailing list: https://launchpad.net/~openstack > >>> Post to : openstack@lists.launchpad.net > >>> Unsubscribe : https://launchpad.net/~openstack > >>> More help : https://help.launchpad.net/ListHelp > >>> > >> _______________________________________________ > >> Openstack-operators mailing list > >> openstack-operat...@lists.openstack.org > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > _______________________________________________ > Openstack-operators mailing list > openstack-operat...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp