On 19/01/16 11:33, zhu4236926 wrote:
Hi guys,
I find a interesting problem in Juno version.
     First, I create a new stack, it contains three resources, e.g.  (In
my test, there are six resources)
heat_template_version: 2014-10-16
resources:
     volume1:
         type: OS::Cinder::Volume
         properties: {name: test1, size: 2}
     volume2:
         type: OS::Cinder::Volume
         properties: {name: test2, size: 2}
volume3:
         type: OS::Cinder::Volume
         properties: {name: test3, size: 2}
     While the stack is creating,  I delete this stack, at this time,
some resources created complete, some resources may be in creating,
e.g. volume3 is creating in Green Thread 1, the volume test3 is creating
in cinder and volume id is not return, so the resource id of volume3 is
none.
Now stack start deleting in Green Thread 2,  because the resource id of
volume3 is none, it returns and deletes success, but the volume test3
has been created success in cinder and not deleted by heat, due to the
resource id of volume3 is none.
     So how to solve this problem, or this bug has been fixed?

Good question. I don't think is actually solvable in general, because every OpenStack service has a short window in which you can lose the response to a call and then not be able to tell whether it succeeded or not. However, we can hope to minimise the number of ways to lose the response.

I think the solution should be to stop the existing thread in the first instance by raising the ForcedCancel exception at the next sleep. This would ensure that we would only stop threads at an explicit 'yield' point (i.e. between handle_create and check_create_complete). Our current reliance on stopping the greenthread itself means that it is liable to be killed whenever eventlet gets control (which may be during a sleep(), but equally could be when doing I/O). We should give it a while to stop itself before then moving on to stopping the greenthread.

AFAICT this won't have changed since Juno.

cheers,
Zane.

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to