[qa][openstackclient] Debugging devstack slowness
> On Aug 6, 2019, at 3:44 PM, Dean Troyer <dtroyer at gmail.com> wrote:
> On Tue, Aug 6, 2019 at 11:42 AM Chris Dent <cdent+os at anticdent.org> wrote:
>> If we are in a situation where name to id and id to name
>> translations are slow at the services' API layer, isn't that a
>> really big bug? One where the fixing is beneficial to everyone,
>> including devstack users?
> While the name->ID lookup is an additional API round trip, it does not
> cause an additional python startup scan, which is the major killer
> here. In fact, it is possible that there is more than one lookup and
> that at least one will always be done because we do not know if that
> value is a name or an ID. The GET is done in any case because nearly
> every time (in non-create operations) we probably want the full object
> I also played with starting OSC as a background process a while back,
> it actually does work pretty well and with a bit more error handling
> would have been good enough(tm). The major concern with it then
> was it was not representative of how people actually use OSC and
> changed the testing value we get from doing that.
>  Basically run interactive mode in background, plumb up
> stdin/stdout to some descriptors and off to the races.
> Dean Troyer
> dtroyer at gmail.com
I made some notes about the plugin lookup issue a while back  and I looked at that again the most recent time we were in Denver , and came to the conclusion that the implementation was going to require more changes in osc-lib than I was going to have time to figure out on my own. Unfortunately, itâ??s not a simple matter of choosing between looking at 1 internal cache or doing the pkg_resource scan because of the plugin version management layer osc-lib added.
In any case, I think weâ??ve discussed the fact many times that the way to fix this is to not scan for plugins unless we have to do so. We just need someone to sit down and work on figuring out how to make that work.