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

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Monty Taylor
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: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [publiccloud-wg] Serving vendor json from RFC 5785 well-known dir

Mohammed Naser
On Sun, Nov 4, 2018 at 4:12 PM Monty Taylor <[hidden email]> wrote:

>
> 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.

Mohammed likes this idea and would like to present this for you to hack on:
https://vexxhost.com/.well-known/openstack/client

> 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?

I really like this idea, the only concern is fallbacks.  I can imagine
that in some
arbitrary world, things might get restructured in a web structure and that URL
magically disappears but shifting the responsibilities on the provider rather
than maintainers of this project is a much cleaner alternative, IMHO.

> Monty
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: [hidden email]?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Mohammed Naser — vexxhost
-----------------------------------------------------
D. 514-316-8872
D. 800-910-1726 ext. 200
E. [hidden email]
W. http://vexxhost.com

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [publiccloud-wg] Serving vendor json from RFC 5785 well-known dir

Thierry Carrez
In reply to this post by Monty Taylor
Monty Taylor wrote:
> [...]
> 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.
> [...]
> What do people think?

I love the idea of public clouds serving that file directly, and the
user experience you get from it. The only two drawbacks on top of my
head would be:

- it's harder to discover available compliant openstack clouds from the
client.

- there is no vetting process, so there may be failures with weird
clouds serving half-baked files that people may blame the client tooling
for.

I still think it's a good idea, as in theory it aligns the incentive of
maintaining the file with the most interested stakeholder. It just might
need some extra communication to work seamlessly.

--
Thierry Carrez (ttx)

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [publiccloud-wg] Serving vendor json from RFC 5785 well-known dir

Mohammed Naser


Sent from my iPhone

> On Nov 5, 2018, at 10:19 AM, Thierry Carrez <[hidden email]> wrote:
>
> Monty Taylor wrote:
>> [...]
>> 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.
>> [...]
>> What do people think?
>
> I love the idea of public clouds serving that file directly, and the user experience you get from it. The only two drawbacks on top of my head would be:
>
> - it's harder to discover available compliant openstack clouds from the client.
>
> - there is no vetting process, so there may be failures with weird clouds serving half-baked files that people may blame the client tooling for.
>
> I still think it's a good idea, as in theory it aligns the incentive of maintaining the file with the most interested stakeholder. It just might need some extra communication to work seamlessly.

I’m thinking out loud here but perhaps a simple linter that a cloud provider can run will help them make sure that everything is functional.

> --
> Thierry Carrez (ttx)
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: [hidden email]?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [publiccloud-wg] Serving vendor json from RFC 5785 well-known dir

Chris Dent-2
In reply to this post by Monty Taylor
On Sun, 4 Nov 2018, Monty Taylor wrote:

> 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.

Sounds like a good plan.

I'm still a vexed that we need to know a cloud's primary host, then
this URL, then get a url for auth and from there start gathering up
information about the services and then their endpoints.

All of that seems of one piece to me and there should be one way to
do it.

But in the absence of that, this is a good plan.

> What do people think?

I think cats are nice and so is this plan.

--
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [publiccloud-wg] Serving vendor json from RFC 5785 well-known dir

Monty Taylor
In reply to this post by Mohammed Naser
On 11/5/18 3:21 AM, Mohammed Naser wrote:

>
>
> Sent from my iPhone
>
>> On Nov 5, 2018, at 10:19 AM, Thierry Carrez <[hidden email]> wrote:
>>
>> Monty Taylor wrote:
>>> [...]
>>> 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.
>>> [...]
>>> What do people think?
>>
>> I love the idea of public clouds serving that file directly, and the user experience you get from it. The only two drawbacks on top of my head would be:
>>
>> - it's harder to discover available compliant openstack clouds from the client.
>>
>> - there is no vetting process, so there may be failures with weird clouds serving half-baked files that people may blame the client tooling for.
>>
>> I still think it's a good idea, as in theory it aligns the incentive of maintaining the file with the most interested stakeholder. It just might need some extra communication to work seamlessly.
>
> I’m thinking out loud here but perhaps a simple linter that a cloud provider can run will help them make sure that everything is functional.

In fact, once we get it fleshed out and support added - perhaps we could
add a tempest test that checks for a well-known file - and include it in
compliance testing. Basically - if your cloud publishes a vendor
profile, then the information in it should be accurate and should work,
right?


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [publiccloud-wg] Serving vendor json from RFC 5785 well-known dir

Monty Taylor
In reply to this post by Mohammed Naser
On 11/5/18 3:21 AM, Mohammed Naser wrote:

>
>
> Sent from my iPhone
>
>> On Nov 5, 2018, at 10:19 AM, Thierry Carrez <[hidden email]> wrote:
>>
>> Monty Taylor wrote:
>>> [...]
>>> 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.
>>> [...]
>>> What do people think?
>>
>> I love the idea of public clouds serving that file directly, and the user experience you get from it. The only two drawbacks on top of my head would be:
>>
>> - it's harder to discover available compliant openstack clouds from the client.
>>
>> - there is no vetting process, so there may be failures with weird clouds serving half-baked files that people may blame the client tooling for.
>>
>> I still think it's a good idea, as in theory it aligns the incentive of maintaining the file with the most interested stakeholder. It just might need some extra communication to work seamlessly.
>
> I’m thinking out loud here but perhaps a simple linter that a cloud provider can run will help them make sure that everything is functional.

I've got an initial patch up:

WIP Support remote vendor profiles https://review.openstack.org/616228

it works with vexxhost's published vendor file.


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev