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
The results API server should have a watcher for the configmap.
Actual Behavior
The results API server doesn't take into account changes done to configmap. We need to delete the API server pod and wait for a restart. This is different from other components' behavior.
The text was updated successfully, but these errors were encountered:
khrm
added
kind/bug
Categorizes issue or PR as related to a bug.
and removed
kind/bug
Categorizes issue or PR as related to a bug.
labels
Sep 25, 2023
@khrm IMO this should be broken down in two parts and implemented in different project. For example.
In tekton results project, watching the configuration through FSevents should be implemented and it should only allow changing parameters that doesn't require restart, like LogLevel. Changing other parameters like Port and Dbname would break the service if we only restart the Pod. Moreover, if there is only one replica running, this would impact the service for some time, which can in the middle of log transmission and that is non-recoverable.
The other configuration changes which involve restarting the API server should be implemented in the Tekton Operator project, as that manages the lifecycle of the whole tekton results service.
Expected Behavior
The results API server should have a watcher for the configmap.
Actual Behavior
The results API server doesn't take into account changes done to configmap. We need to delete the API server pod and wait for a restart. This is different from other components' behavior.
The text was updated successfully, but these errors were encountered: