I took a look to old traces[1] (ocata - no uwsgi). If you take the first RPC in the trace (schedule_and_build_instances), you only get the receiver trace (the conductor) not the sender (the api). It's likely the issue was already here. They are also other cases in which you only get one of the two parts of the RPC (e.g see object_action compute->conductor when instance states are updated).
So my feeling is that it's not related to uwsgi but really rely on the fact that the test[2] is interpreted too early (at import time).
I took a look to old traces[1] (ocata - no uwsgi). If you take the first RPC in the trace (schedule_ and_build_ instances) , you only get the receiver trace (the conductor) not the sender (the api). It's likely the issue was already here. They are also other cases in which you only get one of the two parts of the RPC (e.g see object_action compute->conductor when instance states are updated).
So my feeling is that it's not related to uwsgi but really rely on the fact that the test[2] is interpreted too early (at import time).
[1]: http:// enos.irisa. fr/html/ wan_g5k/ cpt01-osp/ cpt01-osp- lat0/root/ rally_home/ trace-boot- and-delete. yaml.html /github. com/openstack/ nova/blob/ a4fc1bcd08c1232 4070fde5e500366 ff821d468f/ nova/profiler. py#L68
[2]: https:/