[openstack-dev] [heat]Delete the stack while the status of stack is CREATE_IN_PROGRESS?

Zane Bitter zbitter at redhat.com
Tue Jan 19 22:56:34 UTC 2016

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 

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.


More information about the OpenStack-dev mailing list