Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Results API server should watch configmap #621

Open
khrm opened this issue Sep 25, 2023 · 3 comments
Open

Results API server should watch configmap #621

khrm opened this issue Sep 25, 2023 · 3 comments
Assignees
Labels
kind/feature Categorizes issue or PR as related to a new feature.

Comments

@khrm
Copy link
Contributor

khrm commented Sep 25, 2023

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.

@khrm 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
Copy link
Contributor Author

khrm commented Sep 25, 2023

/kind feature

@tekton-robot tekton-robot added the kind/feature Categorizes issue or PR as related to a new feature. label Sep 25, 2023
@khrm khrm added the Hacktoberfest Categorizes issue as one for Hacktoberfest 2021 label Sep 25, 2023
@sayan-biswas sayan-biswas self-assigned this Oct 18, 2023
@sayan-biswas
Copy link
Contributor

Should also watch secrets, because the DB details and TLS details.

@sayan-biswas sayan-biswas removed the Hacktoberfest Categorizes issue as one for Hacktoberfest 2021 label Oct 26, 2023
@sayan-biswas
Copy link
Contributor

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature.
Projects
None yet
Development

No branches or pull requests

3 participants