Describe the bug
When both Central manager and Access point MIG template are changed in the same plan, there is a risk that Access point config object is deleted after being overwritten.
Steps to reproduce
Steps to reproduce the behavior:
- Deploy HTCondor
- Change the configuration of the central manager and the access point, like the disk size
Expected behavior
After deployment, the config object should be in the bucket
Actual behavior
- The AP config object is marked for deletion because the CM IP is "known after apply".
- CM is redeployed with the new configuration, but the IP is reused.
- The new AP config object is deployed using the same name as the previous one because the config is actually the same (because the IP has not changed after all).
- AP template is updated
- The previous AP config object is deleted, but as it is the same name as the newer AP config object, it is also the new AP config object.
Version (gcluster --version)
1.36
According to the code within main branch, it should also affects the latest version (1.42 as of today).
Additional context
I can see multiple ways to solve the issue:
- Allocate IPs outside of the MIG defintion to make them stable upon reconfiguration
- Remove the IP from the computation of the hash
- Add a null_resource that would be recreated when config changes, and use its ID instead of the hash of the config
I think the easiest and more robust way would be the null_resource, but I would be glad to have your opinion on the subject.
I can definitely implement the fix as soon as we agree on how to solve it.
Describe the bug
When both Central manager and Access point MIG template are changed in the same plan, there is a risk that Access point config object is deleted after being overwritten.
Steps to reproduce
Steps to reproduce the behavior:
Expected behavior
After deployment, the config object should be in the bucket
Actual behavior
Version (
gcluster --version)1.36
According to the code within main branch, it should also affects the latest version (1.42 as of today).
Additional context
I can see multiple ways to solve the issue:
I think the easiest and more robust way would be the null_resource, but I would be glad to have your opinion on the subject.
I can definitely implement the fix as soon as we agree on how to solve it.