Comment 3 for bug 1333162

I am observing this with juju 1.25.0 and 1.25.1(proposed) on the openstack provider (Kilo).

The work-around for secgroup cleanup isn't viable for deployment automation where the operator does not control the moments between destroy and deploy.

When the situation arises, it causes all subsequent deployments to fail due to bootstrap errors. This requires human interaction to resolve, short of programmatically doing secgroup housekeeping, and patching that housekeeping into juju test, amulet and/or bundletester.

In OpenStack charm testing, we have 20+ jenkins slaves, each with unique juju environments, all operating against a private cloud via the juju openstack provider. Last night, all slave enviros entered this "Multiple security_group matches" state, and are unusable. I plan to inspect and remove duplicate secgroups to dig more, but I seek a more clever provider solution.