This feature has two intents:
1. Ensure resources are cleanup so that we have uninterrupted testing
and do not accrue extra costs
2. We want to report a failure when destroy-controller fails to
cleanup.
The way security groups and interfaces are being handled does not meet goal 2. It cannot report that destroy-controller failed to clean up for this test run, because it does not know that the security groups were created by this test run.
The doc even suggests "Match security groups/firewalls by controller uuid in the name or in tags/metadata".
Since the doc was written, goal 2 has become more important than goal 1, because our existing cleanup scripts are doing a good job and juju itself is better-behaved.
I have had a chance to look at the design doc: https:/ /docs.google. com/document/ d/1vi94tBGWf5Ui WIIoer5Hn8Un9u7 PqauX8fnF2iNIQp A/edit#
This feature has two intents:
1. Ensure resources are cleanup so that we have uninterrupted testing
and do not accrue extra costs
2. We want to report a failure when destroy-controller fails to
cleanup.
The way security groups and interfaces are being handled does not meet goal 2. It cannot report that destroy-controller failed to clean up for this test run, because it does not know that the security groups were created by this test run.
The doc even suggests "Match security groups/firewalls by controller uuid in the name or in tags/metadata".
Since the doc was written, goal 2 has become more important than goal 1, because our existing cleanup scripts are doing a good job and juju itself is better-behaved.