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 neutron)? 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. Thoughts? [0] http://lists.openstack.org/pipermail/openstack-dev/2017-March/113099.html [1] http://eavesdrop.openstack.org/irclogs/%23openstack-dev/%23openstack-dev.2017-03-02.log.html#t2017-03-02T13:49:19 [2] https://github.com/openstack/nova/blob/37cd9a961b065a07352b49ee72394cb210d8838b/nova/context.py#L102-L106 [3] https://developer.openstack.org/api-ref/identity/v3/index.html?expanded=get-service-catalog-detail#authentication-and-token-management -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170302/d531f7df/attachment.html>