On 01/04/2019 09:43, Jens Harbott wrote:
On Thu, 2019-03-28 at 16:49 +0100, Thomas Goirand wrote:
Hi,
During the summit in Tokyo (if I remember well), Sean Dague lead a discussion about removing the need for having 3 endpoints per service. I was very excited about the proposal, and it's IMO a shame it hasn't been implemented. Everyone in the room agreed. Here the content of the discussion as I remember it:
<discussion in Tokyo> 1/ The only service that needed the admin endpoint was Keystone. This requirement is now gone. So we could get rid of the admin endpoint all together.
2/ The need for an interal vs public endpoint was only needed for accounting (of for example bandwidth when uploading to Glance), but this could be work-around by operators by using intelligent routing. So we wouldn't need the internal endpoint.
This makes us only need the public endpoint, and that's it.
Then, there are these %(tenant_id)s bits in the endpoints which are also very much annoying, and could be removed if the clients were smarter. These are still needed, apparently, for: - cinder - swift - heat </discussion in Tokyo>
Is anyone planning to implement (at least some parts of) the above?
For me as an operator, the distinction between internal and public endpoints is helpful, as it allows to easily set up extended filtering or rate limiting for public services without affecting internal API calls, which in most deployments cause the majority of requests.
If 2/ were implemented a class of deployment where the cloud control plane is isolated from any public networks becomes difficult to engineer. There is currently no requirement for there to be connectivity between the control plane and public networks, so 2/ results in the required architecture becoming more opinionated and reduces choices for the deployer. In openstack-ansible (and no doubt other deployment projects) a wide range of topologies are supported, from simplistic networks where internal and public are the same subnet, through to full isolation. We have deployers who choose to sit at various points along that spectrum as their particular situation requires. 2/ seems to require deployers to in some way NAT or route between their control plane network and the public endpoint, something that I expect most people do right now anyway. However this is not universal and there are set of OSA users (myself included) with non-routable control planes who would like to keep them that way.
I'm not sure what "intelligent routing" is meant to be, but it sounds more complicated and unstable than the current solution.
I also don't understand what this would mean in practice. Jon.