bug: ingress stuck in pending/deleting #982
Comments
|
Hi @Signum , have you enabled the proxy from server list ? |
|
Thanks for the swift response, @tanmoysrt. It seems I had not: Enabling ingress proxy as "Active"… The ingresses went into "Failed" and after waiting 1-2 minutes, they are now gone. Thanks. Continuing my journey. |
|
I have a domain in my list in "failed" state and it's not going away. What's going on? |
Can you share few Infos, whether the proxy is enabled for any server ? |
|
Reproducable steps are difficult because this is an experimental setup and I do not really know what lead to this state. I try to remember... I added a server, proxy disabled. I added a domain for an app. Deployed the app from a GitLab repo, building a docker file to that server. Domain stuck in "pending" state, probably because proxy not enabled. Because I didn't know that and also wondered why the app was deployed but did not start (docker ps -a showed no app on the server) I added another server and redeployed there. Still app deploying but not starting. I tried to delete the domain which got stuck in deleting. I enabled proxy on the second server, domain went into failed state. And that's where it's sitting now. |
|
@HWiese1980 |
|
Sure can.
|
|
This is from this morning. The domain has been in this state for more than 12 hours or so now. |
If proxy is working, just try to recreate the rule |
|
Nope, doesn't work. It remains in "failed" state. I see no indication of errors in the system log. I initiated "Recreate & Fix" at around 14:10. Here's the system log. The "No change in haproxy service" messages do not seem to be related to the action. |
|
Hi @HWiese1980 Also, swiftwave is latest right ? |
|
SwiftWave is v2.2.20-1. I've switched proxy off and on and off and on, and also tried to delete/recreate/fix etc. the ingress rule in multiple constellations. It just persists. I can't get rid of it. A potentially "dangerous" force delete action would be convenient. Or an overwrite option when creating a new rule with the same parameters that simply (after a confirmation) overwrites all the configs of the existing rule and behaves as if it was a new rule. |
|
I think I've tried every possible permutation of settings now, including waiting. The ingress rule just won't disappear. |
|
@HWiese1980 |
|
@HWiese1980 Go to your proxy server and you can run - cat /var/lib/swiftwave/haproxy/haproxy.cfg |
|
Sure. There are no domain names in the config. |
|
This may be related to my setup. My Swiftwave runs behind a Caddy reverse proxy. I had to set up Let's Encrypt during creating the application. I do not need to use Let's Encrypt from Swiftwave because the Caddy reverse proxy in front of it takes care of handling certificate creation and TLS termination. I was able to recreate the behavior by completely starting over with SwiftWave. Remember: Swiftwave runs behind a reverse proxy (in my case Caddy). The internet facing domain name is already configured in Caddy, including wildcard for the Swiftwave ingress rules and TLS certificate issued through Let's Encrypt. Steps:
|
|
@HWiese1980 |
|
My workhorse Caddy is in the same network, on the same host (Proxmox) but not in the same VM. And it is unfortunately not the only Caddy in my setup. There are actually two Caddys running. One is facing the internet (on a virtual server I hired from some service provider) and only and exclusively acting as a bastion host gateway, forwarding all and solely incoming :80 and :443 traffic to my actual workhorse Caddy on my Proxmox. The workhorse Caddy is which does the routing to the different VMs (including Swiftwave) and TLS termination. |
|
Ah, the connection between the bastion host gateway Caddy and the workhorse Caddy is done through Wireguard. |
|
It might have helped to set the |
|
No, it has not helped to set the management_node_address to 127.0.0.1. I was able to destroy the app after doing so (maybe because I had to restart swiftwave), but now I am at the start again. An ingress rule I cannot delete because it's stuck in failed, and a |
|
Swiftwave is trying to destroy the app again, meanwhile I'm doing |
|
@HWiese1980 |
|
Aaah, yeah, that may be the reason. Good catch. If this is the reason (and it looks so), I would suggest to somehow catch that error. A simple "failed" is a little ambiguous. I would have expected to see something like that in the logs. |
|
Okay, this has fixed at least the issue with undeletable and stuck ingress rules. So this is kind of solved (aside from maybe some more detailed logging and UX). Thank you for your support! It's been a nice learning. |
|
@HWiese1980 Because, every time the container fails to start , swarm service try to start again a new one. Without proper integration with Most of the time, this issue doesn't appear because, people are doing this on a fresh instance. In v3.0, doing the integration with 1 level deeper and will not require swarm even. |
Describe the bug
First time user of SwiftWave here. Trying it out on a Debian 12 VM in the local network. Installation was quick and flawless.
I have now created a new app running Wordpress with MariaDB from the App Store. I figured that my ingress would not work properly so I tried to remove it and create a new one with the proper FQDN. However the old ingress is not removed after several minutes and the new one is still pending:
The server's log shows:
Are you working on this issue?
No
The text was updated successfully, but these errors were encountered: