I don't think any clients truly implement this behavior *yet*, but each
service should return a multiple choice response (e.g.
http://keystone.openstack.org/api_curl_examples.html#id2 ) containing links
to each API version (/v1, /v2, /v3), and their status (e.g. deprecated,
current, beta, etc). Ideally the client should automatically use the latest
stable endpoint it understands, and allow the user to override the
selection.
-Dolph
On Wed, May 2, 2012 at 9:58 AM, Matt Joyce <m...@nycresistor.com> wrote:
> Actually this ties into a thought I was having this morning.
>
> How do we handle API versioning? I mean I would assume that we'd want
> to poll the API server and see which versions are available and offer
> command sets that are relevant. Silencing API version specific
> commands that are not available as well as administrative commands
> that are not as well seems wholly feasible depending on how we are
> tracking API versioning inside of the client.
>
> So I suppose the question is... how does the client approach API
> versioning?
>
> -Matt
>
> On Wed, May 2, 2012 at 6: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
