<div dir="ltr">Hi Sukhdev,<br><div class="gmail_extra"><br></div><div class="gmail_extra">Some comments inline.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Salvatore<br><br><div class="gmail_quote">On 23 January 2014 03:10, Sukhdev Kapur <span dir="ltr"><<a href="mailto:sukhdev@aristanetworks.com" target="_blank">sukhdev@aristanetworks.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi All, <div><br></div><div>During tempest sprint in Montreal, as we were writing API tests, we noticed a behavior which we believed is an issue with the Neutron API (or perhaps documentation or both)</div>
<div>
<br></div><div>Let me start with a question: </div><div><br></div><div>If one executes an api to create/delete/update a neutron resource, what is the API's contract with the user? In other words, if a user gets a response code 204 for a delete operation or 201 for create operation - should they assume that the operation is successfully completed? </div>
</div></blockquote><div><br></div><div><br></div><div>The contract is, or at least should be, the one dictated by the meaning of HTTP status code: <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html">http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html</a></div>
<div>(The should in the previous paragraph comes from the awareness that it's not like that at the moment).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">
<div><br></div><div>Based upon the API document, the answer seems to be YES. </div><div>Based upon the behavior answer seems to be MAYBE - what does this mean? </div><div>It simply means that Neutron DB has been updated, but, the back-ends may not have completed the operation. </div>
</div></blockquote><div><br></div><div>Indeed an asynchronous POST request should probably return a 202. 201 Here means that the configuration object has been created.</div><div>Whether that object is actually available for use, it depends on its operational status.</div>
<div>However, for instance nova-api returns 200 for create server operations. So, there is ample room for confusion and discussion.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">
<div><br></div><div>This means, as an example, if a create operation is performed on a same resource immediately after it has been successfully deleted (i.e. 204 returned), there is a possibility that create operation may fail. </div>
</div></blockquote><div><br></div><div>I'm not sure you can create a resource after you deleted it! If you delete a resource, then the resource should exist in the first place, and should have been therefore be created already!</div>
<div><br></div><div>If you're referring to what happens if a resource is deleted after the create request has been processed and fulfilled, then the answer is that the end state will be consistent as long as the two operations are not applied out of order.</div>
<div>For instance, a problem would arise if things are executed in the following order:</div><div><br></div><div>1) API Create request</div><div>2) API Delete request</div><div>3) Agent Delete process (which would be a no-op)</div>
<div>4) Agent Create process</div><div><br></div><div>In the case of neutron ports, this can't happen because it's the agent which initiates the workflow when a new port is found.</div><div>However, the current code in theory allows for out-of-order processing of port update requests, which might be dangerous. There are patches under review for fixing this.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">
<div><br></div><div>If the tests (or real life applications) are not written carefully, there is a possibility of intermittent failures, and they will become very apparent in a stress type situations.</div></div></blockquote>
<div><br></div><div>Well, we are seeing plenty of these intermittent failures, especially in gate tests.</div><div>In my personal opinion this also happens because consumers of the neutron API are seldom using the operational state indicator, which, at least for ports and routers, is reliable. Unfortunately other resources, such as Floating IPs and security groups are currently lacking this indicator, but we're working on that as well.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div> </div><div><br></div>
<div>We discussed this with some of Neutron core developers who were present in the room and they shared their wisdom on the subject. We decided that we put this out on the mailing list for the benefit of wider audience - and, hence the motivation of this email. </div>

<div><br></div><div>Are there any plans to address or document this? </div></div></blockquote><div><br></div><div>About documentation is worth mentioning that the Neutron API does not make any guarantee regarding the completion of the operation when the  API call returns; users should always check the operational status. I believe this is documented. If not, this must be added.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><span class=""><font color="#888888"><div>
<br></div><div>-Sukhdev</div><div><br></div><div><br></div><div> <br></div></font></span></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>