Zaqar queue can be inadvertently deleted

[Jason Dunsmore]

Zaqar creates queues lazily, which causes unexpected results in Heat.

To reproduce:

$ openstack stack create -t http://paste.openstack.org/raw/587209/ zaqar1

$ openstack queue list
+------+
| Name |
+------+
| foo |
+------+

$ openstack stack create -t http://paste.openstack.org/raw/587209/ zaqar2

$ openstack queue list
+------+
| Name |
+------+
| foo |
+------+

$ openstack stack delete --yes zaqar2

$ openstack queue list

(no output)

Deleting the zaqar2 stack causes the zaqar queue from the original zaqar1 stack to be deleted.

[Thomas Herve (therve)]

Queues have been made to look like topics nowadays, so that behavior doesn't surprise me that much, but I can see how it can be confusing. It also a bit dangerous as you can lose messages. I'm not exactly sure what to do though. I don't think there is a bug in Zaqar. I can see 2 things in Heat:

1) Fail if the queue pre-exists in Heat. I don't think it's a backward compatible change, so we'd need to add a flag to get this behavior. But that's a good way to ensure that the queue belongs to the stack somewhat.

2) Don't delete the queue. It leads to some objects lying around, which is a bit sad.

What do you think?

[Jason Dunsmore (jasondunsmore)]

The first option would work if queues were only created by Heat. A pre-existing queue could be unknowingly lazy-created and then deleted outside of Heat. Also, having to pass a flag to get this behavior would make it a lot less useful. I think the second option is safer.

BTW, the same problem exists for the Zaqar subscription resource I'm working on. The second solution works well for subscriptions since they are auto-deleted after the TTL is reached.

[Zane Bitter (zaneb)]

One thing we can do is make the 'name' property of OS::Zaqar::Queue optional. That way people could get a randomly-named queue by default with no danger of sharing across stacks.

[Feilong Wang (flwang)]

TBH, I'm not familiar with the user case of Zaqar in Heat(just for tracking the stack status?), but if Heat would like to share the same queue between two stacks. Then, Heat needs to manage it. May I know why Heat wants to share the same queue for different stack creation? Thanks.

[Thomas Herve (therve)]

There is not really a usecase for sharing the queue between stacks, it's just that there is nothing preventing it.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/404834

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/404834
Committed: https://git.openstack.org/cgit/openstack/heat/commit/?id=01487ebbbbceb07e9ffc604fe64a08d7ed27d995
Submitter: Jenkins
Branch: master

commit 01487ebbbbceb07e9ffc604fe64a08d7ed27d995
Author: Zane Bitter <email address hidden>
Date: Tue Nov 22 11:42:23 2016 -0500

    Make the name of a Zaqar queue optional

    There's no reason to force the user to specify the name of a Zaqar queue.
    In fact, doing so makes it difficult for users to create multiple instance
    of the same template without having all of the messages go into a single
    queue (and without deleting the shared queue when one of the stacks is
    deleted).

    We now autogenerate a sensible randomised name if none is provided.

    Change-Id: I5195d8c0dd413a8f1bd28c2a8ef7a3191c74f882
    Partial-Bug: #1637304

[Jason Dunsmore (jasondunsmore)]

Zane, can we close this bug or is there something else that needs to be addressed?