[openstack-dev] [publiccloud-wg] Serving vendor json from RFC 5785 well-known dir

Monty Taylor mordred at inaugust.com
Sun Nov 4 15:12:13 UTC 2018


Heya,

I've floated a half-baked version of this idea to a few people, but 
lemme try again with some new words.

What if we added support for serving vendor data files from the root of 
a primary URL as-per RFC 5785. Specifically, support deployers adding a 
json file to .well-known/openstack/client that would contain what we 
currently store in the openstacksdk repo and were just discussing 
splitting out.

Then, an end-user could put a url into the 'cloud' parameter.

Using vexxhost as an example, if Mohammed served:

{
   "name": "vexxhost",
   "profile": {
     "auth_type": "v3password",
     "auth": {
       "auth_url": "https://auth.vexxhost.net/v3"
     },
     "regions": [
       "ca-ymq-1",
       "sjc1"
     ],
     "identity_api_version": "3",
     "image_format": "raw",
     "requires_floating_ip": false
   }
}

from https://vexxhost.com/.well-known/openstack/client

And then in my local config I did:

import openstack
conn = openstack.connect(
     cloud='https://vexxhost.com',
     username='my-awesome-user',
     ...)

The client could know to go fetch 
https://vexxhost.com/.well-known/openstack/client to use as the profile 
information needed for that cloud.

If I wanted to configure a clouds.yaml entry, it would look like:

clouds:
   mordred-vexxhost:
     profile: https://vexxhost.com
     auth:
       username: my-awesome-user

And I could just

conn = openstack.connect(cloud='mordred-vexxhost')

The most important part being that we define the well-known structure 
and interaction. Then we don't need the info in a git repo managed by 
the publiccloud-wg - each public cloud can manage it itself. But also - 
non-public clouds can take advantage of being able to define such 
information for their users too - and can hand a user a simple global 
entrypoint for discover. As they add regions - or if they decide to 
switch from global keystone to per-region keystone, they can just update 
their profile file and all will be good with the world.

Of course, it's a convenience, so nothing forces anyone to deploy one.

For backwards compat, as public clouds we have vendor profiles for start 
deploying a well-known profile, we can update the baked-in named profile 
in openstacksdk to simply reference the remote url and over time 
hopefully there will cease to be any information that's useful in the 
openstacksdk repo.

What do people think?

Monty



More information about the OpenStack-dev mailing list