Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mist_device_gateway_cluster not removing devices on a destroy #67

Open
zbuchheit opened this issue Dec 19, 2024 · 3 comments
Open

mist_device_gateway_cluster not removing devices on a destroy #67

zbuchheit opened this issue Dec 19, 2024 · 3 comments
Assignees
Labels
enhancement New feature or request

Comments

@zbuchheit
Copy link
Contributor

Describe the bug

When attempting to destroy a gateway_cluster it seems the devices are being left in the cluster and causes a subsequent apply to fail with the devices still part of the cluster

To Reproduce

Steps to reproduce the behavior:
TODO

Expected behavior

I would expect for the devices to be removed from the cluster and running an apply to re-create the cluster successfully

Error Message

If applicable, add screenshots or paste the Terraform error message to help explain your problem.

Software

  • OS: [e.g. Windows]
  • Terraform Version [e.g. v1.9.8]
  • Provider Version [e.g. v0.2.6]

Additional context

Add any other context about the problem here.

@zbuchheit zbuchheit added the bug Something isn't working label Dec 19, 2024
@zbuchheit
Copy link
Contributor Author

added for tracking purposes and comms, thanks @tmunzer

@tmunzer
Copy link
Collaborator

tmunzer commented Dec 20, 2024

Hi @zbuchheit,

The only way I found to replicate the issue was to remove the devices part of the cluster from the org_inventory resource without destroying the gateway_cluster (or unassign them from the site).
To be honest I'm not sure I'll be able to find a way to improve this.

However, I'm bringing changes to the device_gateway_cluster resource to not raise an error when a planned cluster must be created but already exists in Mist. The providing is now importing the existing cluster in the state if the node MAC addresses in Mist are matching the planned nodes MAC Address.

tmunzer referenced this issue Dec 20, 2024
Improve the creation resource behavior when one of both of the cluster nodes already belong to a cluster.  The provider will no more raise an error when the existing cluster in the Mist Cloud is matching the planned cluster (same primary node, same secondary node).
@zbuchheit
Copy link
Contributor Author

hmm makes sense. I think that improvement would be a welcomed one and help fix a potential broken scenario

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants