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
Is your feature request related to a problem? Please describe
I've got a Jenkins instance with a pretty big number of jobs.
I've hit the K8s limit on ConfigMap size (1MB), meaning that I had to split my configuration in multiple ConfigMaps.
The problem arises when I delete a ConfigMap.
Since the K8s sidecar is configured to use the METHOD SLEEP, it can't delete the associated file in the Jenkins PVC (probably because of this bug?).
Describe the solution you'd like
From what I understand of the issue, it should be fixed by setting the METHOD to WATCH instead of SLEEP but since I'm not sure why this is not the case currently, I'm not sure it is a good fix.
It looks like watching the ConfigMaps to apply the changes immediately would be desirable to me, maybe I'm not seeing the constraint that led to choosing SLEEP instead?
Would you consider either:
changing the default method to WATCH
or making it configurable via the Values?
Describe alternatives you've considered
I currently remove the config file manually via kubectl but it encourages bad security practices (needlessly elevated privileges, non-CasC-management...).
Additional context
I can open a PR with whatever solution you decide on.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe
I've got a Jenkins instance with a pretty big number of jobs.
I've hit the K8s limit on ConfigMap size (1MB), meaning that I had to split my configuration in multiple ConfigMaps.
The problem arises when I delete a ConfigMap.
Since the K8s sidecar is configured to use the METHOD
SLEEP
, it can't delete the associated file in the Jenkins PVC (probably because of this bug?).Describe the solution you'd like
From what I understand of the issue, it should be fixed by setting the METHOD to
WATCH
instead ofSLEEP
but since I'm not sure why this is not the case currently, I'm not sure it is a good fix.It looks like watching the ConfigMaps to apply the changes immediately would be desirable to me, maybe I'm not seeing the constraint that led to choosing
SLEEP
instead?Would you consider either:
WATCH
Describe alternatives you've considered
I currently remove the config file manually via
kubectl
but it encourages bad security practices (needlessly elevated privileges, non-CasC-management...).Additional context
I can open a PR with whatever solution you decide on.
The text was updated successfully, but these errors were encountered: