[all][ops] Train goal: removing and simplifying the endpoint tripplets?

Jay Pipes jaypipes at gmail.com
Mon Apr 1 12:06:27 UTC 2019


On 04/01/2019 04:43 AM, 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.
> 
> I'm not sure what "intelligent routing" is meant to be, but it sounds
> more complicated and unstable than the current solution.

Maybe Thomas was referring to having Keystone just return a single set 
of endpoints depending on the source CIDR.

Or maybe he is referring to performing rate-limiting using a lower-level 
tool that was purpose-built for it -- something like iptables?

i.e. ACCEPT all new connections from your private subnet/CIDR and jump 
all new connections not in your private subnet to a RATE-LIMIT chain 
that applies rate-limiting thresholds.

In other words, use a single HTTP endpoint and do the rate-limiting in 
the Linux kernel instead of higher-level applications.

Related: this is why having "quotas" for things like # of metadata items 
in Nova was always a terrible "feature" that was abusing the quota 
system as a terrible rate-limiting middleware when things like iptables 
or tc were a more appropriate solution.

Best,
-jay

> Big +1 on dropping the admin endpoint though, now that keystone doesn't
> need it anymore.
> 
> Jens
> 



More information about the openstack-discuss mailing list