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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
