Two environments were active in Azure using the same credentials but different storage-account-name settings. (A sanitized version of environments.yaml is attached.) The two environments were named azure-ci and azure-ci-1. When destroying the former both environments were taken down.
Similar to the report in bug 1335885 I got a warning that the security group could not be deleted and it referenced the storage account associated with the azure-ci-1 environment.
The two environments had six and five machines respectively. After the destroy-environment was run all 11 cloud services and virtual machines were gone. The environments/azure-ci.jenv file was deleted but azure-ci-1.jenv remained. 'juju status -e azure-ci-1' hung and did not report any results as its state server was gone.
The full JUJU_HOME environment as it existed *before* the destroy-environment was executed can be found at chinstrap:~bac/juju-gui-ci.
One thing to note is the first environment used the default True value for availability-sets-enabled while the second one used availability-sets-enabled: false. That was done so we could co-locate Apache on one of the Jenkins servers.
I have tried unsuccessfully to reproduce the issue using minimal environments. One attempt involved bootstrapping two Azure environments with no other machines and tearing down the first. Another involved using juju-quickstart to bring up two environments, each with a second machine deploying the juju-gui. A final attempt repeated the last but had availability-sets-enabled setup as in the original failure. All three experiments failed to reproduce the issue.
Two environments were active in Azure using the same credentials but different storage- account- name settings. (A sanitized version of environments.yaml is attached.) The two environments were named azure-ci and azure-ci-1. When destroying the former both environments were taken down.
Similar to the report in bug 1335885 I got a warning that the security group could not be deleted and it referenced the storage account associated with the azure-ci-1 environment.
The two environments had six and five machines respectively. After the destroy-environment was run all 11 cloud services and virtual machines were gone. The environments/ azure-ci. jenv file was deleted but azure-ci-1.jenv remained. 'juju status -e azure-ci-1' hung and did not report any results as its state server was gone.
The full JUJU_HOME environment as it existed *before* the destroy-environment was executed can be found at chinstrap: ~bac/juju- gui-ci.
One thing to note is the first environment used the default True value for availability- sets-enabled while the second one used availability- sets-enabled: false. That was done so we could co-locate Apache on one of the Jenkins servers.
I have tried unsuccessfully to reproduce the issue using minimal environments. One attempt involved bootstrapping two Azure environments with no other machines and tearing down the first. Another involved using juju-quickstart to bring up two environments, each with a second machine deploying the juju-gui. A final attempt repeated the last but had availability- sets-enabled setup as in the original failure. All three experiments failed to reproduce the issue.
% juju --version utopic- amd64
1.20.12-