github-starred/pangolin
2
0
Fork 0
mirror of https://github.com/fosrl/pangolin.git synced 2026-05-21 09:21:15 -05:00
Code Issues 856 Packages Projects Releases 74 Wiki Activity

Site associations have destructive behavior to resources #410

New Issue
Closed
opened 2025-11-13 11:59:38 -06:00 by GiteaMirror · 3 comments
GiteaMirror commented 2025-11-13 11:59:38 -06:00
Owner
Copy Link

Originally created by @kalikid021 on GitHub (Jun 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 GitHub (Jun 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.
GiteaMirror added the help wanted label 2025-11-13 11:59:38 -06:00
GiteaMirror commented 2025-11-13 11:59:39 -06:00
Author
Owner
Copy Link

@miloschwartz commented on GitHub (Jun 5, 2025):

This makes a lot of sense and would be nicely complemented by some bulk action tools to move/associate resources to different sites. The current functionality is because we delete on cascade for the relations. Hope to improve on this

@miloschwartz commented on GitHub (Jun 5, 2025): This makes a lot of sense and would be nicely complemented by some bulk action tools to move/associate resources to different sites. The current functionality is because we delete on cascade for the relations. Hope to improve on this
GiteaMirror commented 2025-11-13 11:59:39 -06:00
Author
Owner
Copy Link

@kalikid021 commented on GitHub (Jun 5, 2025):

The current functionality is because we delete on cascade for the relations

This was my assumption after it happened, which is why I wanted to raise the issue. I appreciate the quick response, and all the work on this project, it's a great piece of software.

@kalikid021 commented on GitHub (Jun 5, 2025): > The current functionality is because we delete on cascade for the relations This was my assumption after it happened, which is why I wanted to raise the issue. I appreciate the quick response, and all the work on this project, it's a great piece of software.
GiteaMirror commented 2025-11-13 11:59:39 -06:00
Author
Owner
Copy Link

@miloschwartz commented on GitHub (Sep 27, 2025):

This no longer happens because resources don't belong to sites

@miloschwartz commented on GitHub (Sep 27, 2025): This no longer happens because resources don't belong to sites
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
api
authentication
bug
config
dependencies
docker
documentation
enhancement
good first issue
help wanted
Improvement
Look Into
needs investigating
networking
new feature
non-critical bug
potential bug
pull-request
Mirrored from GitHub Pull Request
 question
reverse proxy
Security
stale
ui
wontfix
No Label help wanted
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/pangolin#410
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?