[openstack-dev] [tc][ptls][all] Potential Queens Goal: Implement collection link OR full discovery alignment

Monty Taylor mordred at inaugust.com
Thu Jun 1 16:03:39 UTC 2017


Hey everybody!

I have submitted two potential goals for Queens:

https://review.openstack.org/#/c/468436 - add collection links
https://review.openstack.org/#/c/468437 - full discovery alignment

One is a subset of the other, so the decision is two-fold

* do we do this at all?
* do we do the smaller or the larger of the two?

Both of these are work driven by the version-discovery API-WG specs, 
which are in turn driven by trying to improve the interop story for our 
APIs to include more SDKs/libs than just shade. So the overall story 
here is "implement things to improve life for folks consuming the 
catalog and version discovery"

Quick summaries:

Add Collection Links
--------------------

This is the simpler of the two. It involves adding a "collection" link 
to the list of links in the version discovery documents. That is, this:


     {
       "version": {
         "id": "v2.0",
         "links": [
           {
             "href": "https://image.example.com/v2",
             "rel": "self"
           }
         ],
         "status": "CURRENT"
       }
     }

Becomes this:

     {
       "version": {
         "id": "v2.0",
         "links": [
           {
             "href": "https://image.example.com/v2",
             "rel": "self"
           },
           {
             "href": "https://image.example.com/",
             "rel": "collection"
           }
         ],
         "status": "CURRENT"
       }
     }

The reason for this is as a path to the unversioned discovery document 
on clouds where the versioned endpoint is the thing that's in the 
catalog. The current way to do that is to take the versioned endpoint 
and pop things off of the end.

'collection' is proposed for the rel name. From the list of official 
names: 
https://www.iana.org/assignments/link-relations/link-relations.xhtml it 
seems like the best choice. (If a single-version version document is a 
"Version", then the list of those in the unversioned document seems like 
the "collection" of them)

This one should be _very_ little work per-project. I took a stab at 
implementing this for nova while sitting in the goals room in Boston and 
without any knowledge of how version discovery works in nova I got most 
of it done in about 15 minutes.

Full Discovery Alignment
------------------------

Full discovery alignment includes the collection link work, but also 
includes a few more things. There isn't a TON more per-project coding 
work. Most of the openstack-side work is in adding support to 
keystoneauth - and I've already written most of those patches. The other 
main bit of work is in updating SDKs and libs for other languages to 
implement the consumption support as well - but we've made good contacts 
with folks and can get that done (and will, regardless of the goal)

The main per-project additional things to do after the keystoneauth 
patches land on top of the collection link are:

* modifying devstack plugins and deployment projects to register the 
service using the official name from the service-types-authority
* modifying devstack plugins and deployment projects to register the 
unversioned endpoint in the catalog
* modifying devstack and plugins to stop using "RegionOne" as the region 
name

The goal also calls out a few specific tempest tests we need to write to 
verify discovery works as expected across the board.

I *think* the Full Alignment goal is doable and not a terrible amount of 
per-project work. But as with everything, it is work.

Thoughts?
Monty



More information about the OpenStack-dev mailing list