openstack team mailing list archive

[Doug Hellmann <doug.hellmann@xxxxxxxxxxxxx>]

On Wed, May 2, 2012 at 2:46 PM, Duncan McGreggor <duncan@xxxxxxxxxxxxx>wrote:

> On Wed, May 2, 2012 at 1:56 PM, Matt Joyce <matt@xxxxxxxxxxxxxxx> 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 <duncan@xxxxxxxxxxxxx>
> 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.mathews@xxxxxxxxx>
> 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.hellmann@xxxxxxxxxxxxx>
> >>> 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 <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
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> 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
> >>>
> >> _______________________________________________
> >> Openstack-operators mailing list
> >> Openstack-operators@xxxxxxxxxxxxxxxxxxx
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> _______________________________________________
> Openstack-operators mailing list
> Openstack-operators@xxxxxxxxxxxxxxxxxxx
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>