You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Given the capability you are leveraging, describe your expectation?
The config reloader should start without issues.
Given the expectation, what is the defect you are observing?
After upgrading the Helm chart, which upgrades the config reloader from 0.14.2 to 0.15.0, the reloader began failing with this output on startup:
2024/08/26 09:54:20 Starting NATS Server Reloader v0.15.0
Error: /etc/nats-certs/gateway/tls.crt, does not exist
Using a test pod etc., I have verified that the file exists and is readable.
I suspect the cause is the new logic (added after reloader 0.14.2) that tries to parse out cert files from the config file. This logic doesn't use a real parser, and uses a bunch of gnarly regexps and string manipulating to dig out file names, which I think is a bad idea.
In theory is that on Kubernetes, mounted secrets are actually symlinks that resolve to rather weird paths, and that this trips up the logic somehow:
$ ls /etc/nats-certs/gateway/tls.crt
/etc/nats-certs/gateway/tls.crt -> ..data/tls.crt
The text was updated successfully, but these errors were encountered:
What version were you using?
1.2.2
What environment was the server running in?
Kubernetes 1.29.7 on GKE.
Is this defect reproducible?
Not sure.
Given the capability you are leveraging, describe your expectation?
The config reloader should start without issues.
Given the expectation, what is the defect you are observing?
After upgrading the Helm chart, which upgrades the config reloader from 0.14.2 to 0.15.0, the reloader began failing with this output on startup:
Using a test pod etc., I have verified that the file exists and is readable.
I suspect the cause is the new logic (added after reloader 0.14.2) that tries to parse out cert files from the config file. This logic doesn't use a real parser, and uses a bunch of gnarly regexps and string manipulating to dig out file names, which I think is a bad idea.
In theory is that on Kubernetes, mounted secrets are actually symlinks that resolve to rather weird paths, and that this trips up the logic somehow:
The text was updated successfully, but these errors were encountered: