We should pick a specific HTTP 4xx status code to return in case expected dependant objects are not (yet) present.
Looking e.g. at the Wikipedia page about HTTP status codes, the following all seem vaguely appropriate:
- 409 Conflict: Indicates that the request could not be processed because of conflict in the request, such as an edit conflict between multiple simultaneous update.
- 412 Precondition Failed (RFC 7232) : The server does not meet one of the preconditions that the requester put on the request. Sounds neat, but strictly speaking we would not reply this because of a RFC 7232 compliant precondition header that the requester put on the request, of course.
- 417 Expectation Failed: The server cannot meet the requirements of the Expect request-header field. Again, strictly speaking wrong, as of course we do actually use the Expect request-header field.
- 424 Failed Dependency (WebDAV; RFC 4918): The request failed because it depended on another request and that request failed (e.g., a PROPPATCH). Neat fit, but again - we of course don't do RFC 4918 / WebDAV.
- 442: Totally arbitrary new one, I just made up! May be best and clearer than using an existing one?
I will start with 442, and will let anyone who thinks that there is a more appropriate one please comment here.
Alternatively, we could just use 400 and give a textual explanation.
Or we could try "402 Payment Required" and see if we could make a little money 
Removing GENIUS-122 as an "is blocked by link" - the current design won't need the DataTreeEventCallbackRegistrar.
> initial implementation will focus on doing above for Create events
with the just merged c/72372, this is now on master.
First round covers it for SG / SR; others should replicate this to other Neutron entities.
> If at all and how to apply this to Update
this is now proposed c/73248, but may need some disucssion... will the delta sent in a PUT to modify alway contain all fields? For example, does a PUT to modify an existing SR have to have that security_group_id field, like a POST to create must, or is that optional? Interested in your thoughts jhershbe, MikeKolesnik, thapar...
> and Delete will be considered later under future issues with refined requirements.
Delete probably does not need Dependency Checking - forget that.
shague and I have agree to include this work under the umbrella of "work required for better clustering" (see label and Epic Link he just added), based on a private email exchange where thapar stated the following which jhershbe confirmed with "it makes sense to me to add it here as well." & "Yes, that is my thinking as well." in reply to:
I thought it was more due to Openstack side HA issues. ODL Clustering wise, it will help as netvirt will be much less likely to get notifications out of order. A DS Read on dependency check kinda of ensures that services have already got notifications for earlier resource and will be ready to handle this one. It will help reduce lots of race and out of order issues and probably should help reduce some cross shard read and writes.
> First round covers it for SG / SR; others should replicate this to other Neutron entities.
the best way to organize this is probably with new sub-tasks for specific Neutron entities (TBC).
> the best way to organize this is probably with new sub-tasks for specific Neutron entities (TBC)
I would love someone else to take this over at this point. What's missing is basically just implementing more areAllDependenciesAvailable() methods, by replicating https://git.opendaylight.org/gerrit/#/c/72372/10/transcriber/src/main/java/org/opendaylight/neutron/transcriber/NeutronSecurityRuleInterface.java to all other Neutron entities.
It's not particularly hard to do anymore (now that I've completing creating all the infrastructure that was required for this underneath), but I'm actually clueless about the Neutron entities... 
> take this over at this point