<div class="gmail_extra">I don't think any clients truly implement this behavior *yet*, but each service should return a multiple choice response (e.g. <a href="http://keystone.openstack.org/api_curl_examples.html#id2">http://keystone.openstack.org/api_curl_examples.html#id2</a> ) 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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">-Dolph<br><br><div class="gmail_quote">On Wed, May 2, 2012 at 9:58 AM, Matt Joyce <span dir="ltr"><<a href="mailto:matt@nycresistor.com" target="_blank">matt@nycresistor.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Actually this ties into a thought I was having this morning.<br>
<br>
How do we handle API versioning?  I mean I would assume that we'd want<br>
to poll the API server and see which versions are available and offer<br>
command sets that are relevant.  Silencing API version specific<br>
commands that are not available as well as administrative commands<br>
that are not as well seems wholly feasible depending on how we are<br>
tracking API versioning inside of the client.<br>
<br>
So I suppose the question is... how does the client approach API versioning?<br>
<span class="HOEnZb"><font color="#888888"><br>
-Matt<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Wed, May 2, 2012 at 6:14 AM, Dolph Mathews <<a href="mailto:dolph.mathews@gmail.com">dolph.mathews@gmail.com</a>> wrote:<br>
> I disagree with all three... the line between "admin" and "not admin" is<br>
> going to get very blurry in the long run. Example: I may be a regular user,<br>
> but I've been granted what is "normally" an admin capability on tenant X.<br>
> Does that make me an admin? Do I now need to use two different clients?<br>
><br>
> I also don't think it should be the client's *responsibility* to understand<br>
> what capabilities are required for any given command (ultimately making<br>
> *assumptions* about what the service will allow the user to do), as it's the<br>
> remote service that's ultimately going to enforce it's own policies. It may<br>
> be a decent feature to warn the user something is probably not going to work<br>
> (or better yet, the ability to ask the remote service if something will<br>
> succeed before we attempt it), but the client shouldn't prevent the user<br>
> from trying -- especially by suppressing/isolating features. Horizon is<br>
> going to face the same challenge (hiding/showing capability-relevant UI).<br>
><br>
> tl;dr: openstackclient should be uniformly featured across all OpenStack<br>
> API's ("service", "admin" or otherwise)<br>
><br>
> -Dolph<br>
><br>
> On Tue, May 1, 2012 at 6:55 PM, Doug Hellmann <<a href="mailto:doug.hellmann@dreamhost.com">doug.hellmann@dreamhost.com</a>><br>
> wrote:<br>
>><br>
>> There are a couple of ways to handle that:<br>
>><br>
>> 1. A separate "openstackadmin" CLI that looks for commands using a<br>
>> different plugin namespace, and therefore only loads the admin commands.<br>
>><br>
>> 2. Prefix admin-related commands in the unified cli with "admin" (so<br>
>> "openstack admin create network" or whatever).<br>
>><br>
>> 3. Separate admin apps for each project.<br>
>><br>
>> I think we should avoid 3, since that goes against the spirit of this<br>
>> project. I like #2, but #1 would be easy to implement and could share 99% of<br>
>> the code from the basic openstackclient.<br>
>><br>
>> On Tue, May 1, 2012 at 4:59 PM, Matt Joyce <<a href="mailto:matt@nycresistor.com">matt@nycresistor.com</a>> wrote:<br>
>>><br>
>>> How does this blueprint play into this client.  Is it a separate admin<br>
>>> only client or just a subset of this guy?<br>
>>><br>
>>> <a href="https://blueprints.launchpad.net/nova/+spec/admin-cli" target="_blank">https://blueprints.launchpad.net/nova/+spec/admin-cli</a><br>
>>><br>
>>> -matt<br>
>>><br>
>>> On Tue, May 1, 2012 at 12:28 PM, Dean Troyer <<a href="mailto:dtroyer@gmail.com">dtroyer@gmail.com</a>> wrote:<br>
>>> > On Tue, May 1, 2012 at 2:11 PM, Adam Spiers <<a href="mailto:aspiers@suse.com">aspiers@suse.com</a>> wrote:<br>
>>> >> As of my recent patch, --help is contextual in nova:<br>
>>> ><br>
>>> > I hadn't seen that yet...<br>
>>> ><br>
>>> >> and I have started work on some of the other commands too, so it would<br>
>>> >> be helpful if we could reach a consensus on this soon ... although<br>
>>> >> please let me know if I am wasting my time working on other commands<br>
>>> >> due to any imminent rewrites using python-openstack!<br>
>>> ><br>
>>> > The continued existence of the project-specific commands is really up<br>
>>> > to the projects themselves.  I think it would be great to converge<br>
>>> > them on things like this, but trying to get them all to work the same<br>
>>> > is what led us to openstackclient due to backward compatibility and<br>
>>> > all.  My guess would be that the existing client binaries would live<br>
>>> > through the 'G' release even if we decided to deprecate them now.<br>
>>> ><br>
>>> >> I agree with Dolph - there is a precedent from other well-known<br>
>>> >> programs (git, hg, svn are the first ones I can think of) for --help<br>
>>> >> to behave differently depending on whether or not it was preceded by a<br>
>>> >> subcommand.  So my vote is that we should definitely aim to adhere to<br>
>>> >> this pattern.<br>
>>> ><br>
>>> > How about detailing it in the HIG and once we get a command or two<br>
>>> > implemented with argument parsing we give it a shot?<br>
>>> ><br>
>>> > dt<br>
>>> ><br>
>>> > --<br>
>>> ><br>
>>> > Dean Troyer<br>
>>> > <a href="mailto:dtroyer@gmail.com">dtroyer@gmail.com</a><br>
>>> ><br>
>>> > _______________________________________________<br>
>>> > Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
>>> > Post to     : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
>>> > Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
>>> > More help   : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
>>><br>
>>> _______________________________________________<br>
>>> Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
>>> Post to     : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
>>> Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
>>> More help   : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
>> Post to     : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
>> Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
>> More help   : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
>><br>
><br>
</div></div></blockquote></div><br></div>