Comment 4 for bug 1605089

@Numan, I just read your email and it is really good information. It basically implements Neutron API as async call, and queuing the request within DB transaction, and the ordering is preserved by the journal thread "lock" that is implemented with state PROCESSING plus DB transaction "with_for_update", with the help of some validation functions for dependency checking (e.g. same object cannot be updated by 2 journal threads at the same time).

The dependency problem mentioned by @Amitabha is valid but I think it can be handled, and from ODL ml2 code it is handled by the validation checks (e.g. if a network creation is pending then the port creation depending on it will wait).

However, I didn't figure out how errors are handled with this model. For example, a port is created in Neutron but ODL controller failed to create it although the journal thread successfully sent the request to ODL. And I didn't see how the port states (UP & DOWN) are handled (so does it mean it will just be UP from the beginning?) It would be great if anyone can help answer this question.