Open Stack

Hi Sukhdev,

Some comments inline.

Salvatore

On 23 January 2014 03:10, Sukhdev Kapur <sukhdev at aristanetworks.com> wrote:

> Hi All,
>
> 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)
>
> Let me start with a question:
>
> 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?
>


The contract is, or at least should be, the one dictated by the meaning of
HTTP status code: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
(The should in the previous paragraph comes from the awareness that it's
not like that at the moment).


> Based upon the API document, the answer seems to be YES.
> Based upon the behavior answer seems to be MAYBE - what does this mean?
> It simply means that Neutron DB has been updated, but, the back-ends may
> not have completed the operation.
>

Indeed an asynchronous POST request should probably return a 202. 201 Here
means that the configuration object has been created.
Whether that object is actually available for use, it depends on its
operational status.
However, for instance nova-api returns 200 for create server operations.
So, there is ample room for confusion and discussion.


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

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!

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.
For instance, a problem would arise if things are executed in the following
order:

1) API Create request
2) API Delete request
3) Agent Delete process (which would be a no-op)
4) Agent Create process

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


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

Well, we are seeing plenty of these intermittent failures, especially in
gate tests.
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.


>
>
> 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.
>
> Are there any plans to address or document this?
>

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.


>
> -Sukhdev
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140123/8864789c/attachment.html>