[openstack-dev] [keystone][nova][neutron][cinder] Limiting RPC traffic with keystoneauth

Lance Bragstad lbragstad at gmail.com
Thu Mar 2 18:43:13 UTC 2017

Post PTG there has been some discussion regarding quotas as well as limits.
While most of the discussion has been off and on in #openstack-dev, we also
have a mailing list thread on the topic [0].

I don't want to derail the thread on quotas and limits with this thread,
but today's discussion [1] highlighted an interesting optimization we could
make with keystoneauth and the service catalog. It seemed appropriate to
have it in it's own thread.

We were trying to figure out where to advertise limits from keystone for
quota calculations. The one spot we knew we didn't want it was the service
catalog or token body. Sean elaborated on the stuff that nova does with
context that filters the catalog to only contain certain things it assumes
other parts of nova might need later [2] before putting the token on the
message bus. From an RPC load perspective, this obviously better than
putting the *entire* token on the message bus, but could we take it one
step further? Couldn't we leverage keystone's GET /v3/auth/catalog/ API [3]
in keystoneauth to re-inflate the catalog in the services that need to make
calls to other services (i.e. nova-compute needing to talk to cinder or

I don't think we'd be reducing the number of things put on the queue, just
the overall size of the message. I wanted to start this thread to get the
idea in front of a wider audience, specifically projects that lean heavily
on RPC for inter-service communication. Most of the changes would be in
keystoneauth to do the needful if the token doesn't have a catalog. After
that, each service would have to identify if/where it does any filtering of
the service catalog before placing the token on the message bus.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170302/d531f7df/attachment.html>

More information about the OpenStack-dev mailing list