Re: [openstack-dev] [publiccloud-wg] Serving vendor json from RFC 5785 well-known dir
On 11/5/18 3:21 AM, Mohammed Naser wrote: Sent from my iPhone On Nov 5, 2018, at 10:19 AM, Thierry Carrez 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [publiccloud-wg] Serving vendor json from RFC 5785 well-known dir
On 11/5/18 3:21 AM, Mohammed Naser wrote: Sent from my iPhone On Nov 5, 2018, at 10:19 AM, Thierry Carrez 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [publiccloud-wg] Serving vendor json from RFC 5785 well-known dir
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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [publiccloud-wg] Serving vendor json from RFC 5785 well-known dir
Sent from my iPhone > On Nov 5, 2018, at 10:19 AM, Thierry Carrez 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ 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
Re: [openstack-dev] [publiccloud-wg] Serving vendor json from RFC 5785 well-known dir
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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [publiccloud-wg] Serving vendor json from RFC 5785 well-known dir
On Sun, Nov 4, 2018 at 4:12 PM Monty Taylor 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: openstack-dev-requ...@lists.openstack.org?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. mna...@vexxhost.com
W. http://vexxhost.com
__
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
