Adding a queue to store events that Nova did not have a recieve handler set for might help as well. And have a TTL set on it, or a more advanced reaping logic, for example based on tombstone events invalidating the queue contents by causal conditions. That would eliminate flaky expectations set around starting to wait for receiving events vs sending unexpected or belated events. Why flaky? Because in an async distributed system there is no "before" nor "after", so an external to Nova service will unlikely conform to any time-frame based contract for send-notify/wait-receive/real-completion-fact. And the fact that Nova can't tell what the network backend is (because [1] was not fully implemented) does not make things simpler.
i honestly dont think this is a viable option we have discussed it several times in nova in the past and keep coming to the same conclution either the event shoudl be sent and waited for at that right times or they loose there value.
Yep, agree with Sean here. I definitely don't think that making the system less deterministic is going to make things more reliable. This needs to be a contract between two services that we can depend on. Nova and Neutron both serve the purpose of abstracting the lower-level elements into a service. Making the different technologies they support behave similarly is the reason they exist. --Dan