Open Stack

+1 to Jens point. Internal endpoints seems to be pretty useful for me as well, as you may set internal networks to completely another physical interface (like internal infiniband connections), while leave public endpoints rate limited, and it's pretty easy to configure and maintain. And I guess it might be the case for a pretty big amount of public clouds.

01.04.2019, 11:48, "Jens Harbott" <frickler at offenerstapel.de>:
> 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.
>
> I'm not sure what "intelligent routing" is meant to be, but it sounds
> more complicated and unstable than the current solution.
>
> Big +1 on dropping the admin endpoint though, now that keystone doesn't
> need it anymore.
>
> Jens

-- 
Kind Regards,
Dmitriy Rabotyagov