Site associations have destructive behavior to resources #1405

Closed
opened 2026-04-05 19:24:16 +02:00 by MrUnknownDE · 0 comments
Owner

Originally created by @kalikid021 on 6/5/2025

Please decouple Site associations to resources in regards to removing/rebuilding sites.

I have a service that will pull and re-deploy containers when there is an update. I have 2 sites configured, one in each of 2 separate VLANs. Container images for newt went out earlier in the day, and they were automatically updated by my service. This created an issue with Pangolin where the tunnels were broken, even though the logs showed everything was working. In order to get everything working I had to delete each site, generate a new config, and redeploy the newt containers.

This had a major destructive side effect, any resources that were associated with that site were automatically deleted when the site was deleted, rather than leaving them in the UI to be re-associated with a new/different site.

This creates multiple issues, the most obvious being in a production environment, this would be catastrophic if you have to completely rebuild all the resources associated with a given site, if a new site isn't created first, and the resources moved to the new site, before you delete the site.

There was no warning in the UI that deleting the site would also delete any resources attached to that site, and to re-associate them first. Not having these resources well documented outside of Pangolin, would also create a major problem when trying to recreate the environment.

If resources without a site exist, they should also have a moniker denoting they currently do not have a site associated. and will not function until corrected.

*Originally created by @kalikid021 on 6/5/2025* Please decouple Site associations to resources in regards to removing/rebuilding sites. I have a service that will pull and re-deploy containers when there is an update. I have 2 sites configured, one in each of 2 separate VLANs. Container images for newt went out earlier in the day, and they were automatically updated by my service. This created an issue with Pangolin where the tunnels were broken, even though the logs showed everything was working. In order to get everything working I had to delete each site, generate a new config, and redeploy the newt containers. This had a major destructive side effect, any resources that were associated with that site were automatically deleted when the site was deleted, rather than leaving them in the UI to be re-associated with a new/different site. This creates multiple issues, the most obvious being in a production environment, this would be catastrophic if you have to completely rebuild all the resources associated with a given site, if a new site isn't created first, and the resources moved to the new site, before you delete the site. There was no warning in the UI that deleting the site would also delete any resources attached to that site, and to re-associate them first. Not having these resources well documented outside of Pangolin, would also create a major problem when trying to recreate the environment. If resources without a site exist, they should also have a moniker denoting they currently do not have a site associated. and will not function until corrected.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github/pangolin#1405