Open Stack

On Tue, Aug 6, 2019, at 9:17 AM, Jeremy Stanley wrote:
> On 2019-08-06 08:49:17 -0700 (-0700), Clark Boylan wrote:
> [...]
> > One of the things I found was that using names with osc results in
> > name to id lookups as well. We can avoid these entirely if we
> > remember name to id mappings instead (which my POC does). Any idea
> > if your osc as a service tool does or can do that? Probably have
> > to be more careful for scoping things in a tool like that as it
> > may be reused by people with name collisions across
> > projects/users/groups/domains.
> [...]
> 
> Out of curiosity, could OSC/SDK cache those relationships so they're
> only looked up once (or at least infrequently)? I guess there are
> cache invalidation concerns if an entity is deleted and another
> created out-of-band using the same name, but if it's all done
> through the same persistent daemon then that's less of a risk right?

They could cache these things too. The concern is a valid one too; however, a relatively short TTL may address that as these resources tend to all be used near each other. For example create a router, network, subnet in neutron or a user, role, group/domain in keystone.

That said I think a bigger win would be caching tokens if we want to make changes to caching for osc (I think it can cache tokens but we don't set it up properly in devstack?) Every invocation of osc first hits the pkg_resources cost, then hits the catalog and token lookup costs, then does name to id translations, then does the actual thing you requested. Addressing the first two upfront costs likely has a bigger impact than name to id translations.

Clark