Open Stack

>> 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