Open Stack

On Thu, 2014-02-13 at 08:45 -0600, Dean Troyer wrote:
> FWIW, an early proposal to address this, as well as capability
> discovery, still lives
> at https://etherpad.openstack.org/p/api-version-discovery-proposal.
>  I've lost track of where this went, and even which design summit this
> is from, but I've been using it as a sanity check for the discovery
> bits in OSC.

Yes, i've seen that one. It's more client side how we should work with
it though. If we can standardize the server side response then the
client side becomes much more reusable. 

> 
> On Thu, Feb 13, 2014 at 6:50 AM, Jamie Lennox <jamielennox at redhat.com>
> wrote:
>         6. GET '/' is unrestricted. GET '/vX' is often token
>         restricted.
>         
>         Keystone allows access to /v2.0 and /v3 but most services give
>         a HTTP Unauthorized. This is a real problem for discovery
>         because we need to be able to evaluate the endpoints in the
>         service catalog. I think we need to make these unauthorized.
> 
> 
> I agree, however from a client discovery process point-of-view, you do
> not necessarily have an endpoint until after you auth and get a
> service catalog anyway.  For example, in the specific case of
> OpenStackClient Help command output, the commands listed may depend on
> the desired API version.  To get the endpoints to query for version
> support still requires a service catalog so nothing really changes
> there.

Yes, i had thought of that afterward and we can send the token to the
endpoint. From a standards document though it'd be better if we didn't
have to. 

> And this doesn't even touch on the SC endpoints that include things
> like tenant/project id...

Yuk. Yes, a problem with this is that entries in the service catalog
that have a project id in them don't currently present version
information at that endpoint. I'd be interested in fixing this but as
it's going to need to be backwards compatible with the current state
it's not really a priority. 

>         Please have a look over the wiki page and how it addresses the
>         above and fits into the existing schemes and reply with any
>         comments or problems that you see. Is this going to mess with
>         any pre-existing clients?
> 
> 
> * id: Let's either make this a real semantic version so we can parse
> and use the major.minor.patch components (and dump the 'v') or make it
> an identifier that matches the URL path component.  Right now 

Do we need patch on API versions? I was aiming for standards rather than
improvement here but i guess this is the right time to fix something
like this.

> * updated: I think it would be a friendly gesture to update this for
> unstable changes as the id is likely to not be updated mid-stream.
>  During debugging I would want to be able to verify exactly which
> implementation I was talking to anyway.

So i was thinking the way to do that would be to define two endpoints eg
a stable v3.2 and an unstable v3.3 that reference the same endpoint. 

> 
> There are two transitional things to also consider:
> 
> 
> * We have to produce a discovery mechanism that takes in to account
> the historical authentication URLs published by deployments that
> include a version.  ayoung's Ml thread last week discussed this a bit,
> we should document the approaches that we're testing and why they do
> or do not work.

Right and we need another talk about this, but let's leave this about
defining a standard that new projects should adhere to and slowly moving
the existing ones.  

> * There are real-world deployments that do not configure
> admin_endpoint and/or public_endpoint in keystone.conf.  Discovery is
> really useless if the URL you are given is
> https://localhost:5000/v2.0.  Do we need to talk about another
> horrible horrible hack to deal with these or are these deployments
> going to be left out in the cold?

Right, this is more infuriating with keystone that uses admin_url which
is not defined as either public or internal. Which URL should be present
on that discover page? 

>From the server side to counter this i very specifically put a clause in
the wiki page to say that discover links can be relative and i'll change
that now to SHOULD be relative. This way a link is just defined as
"/v2.0" and you can use whatever host got you to that point. The only
problem i see here is what is the relative "self" link from GET /v2.0
should it just be { "rel": "self", "href": "" }, is "href" excluded or
None?

The client side is going to be ugly again and we should talk but it's
outside scope for this. 

> dt
> 
> 
> -- 
> 
> Dean Troyer
> dtroyer at gmail.com
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev