Revert log sinks to service configuration - #982
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Revert log sinks to service configuration
Problem
Once a log sink was edited through the admin UI (
source = "db"), therewas no way to roll it back to the values defined in the YAML/env/flags
service configuration without manually editing the database or the YAML
file and restarting. Operators who wanted to discard their UI edits and
return to the seeded config had no self-service path.
Solution
Add a "Revert" button on each edited sink row that flips
sourcebackto
"service", then re-syncs the config from the current serviceconfiguration during the next hot-reload — no restart, no YAML editing,
no backend access needed.
How it works
Operator clicks "Revert" on a sink row with
source = "db".A confirm dialog explains the config will be re-synced from the
YAML/flags on the next Apply.
API:
POST /api/v1/log-sinks/{id}/revertcallsLogSinksManager.RevertToService(id)which setssource = "service"on the row. The config blob is not changed here — only the source
flag. The sync happens in the TLS process which has access to the
resolved service parameters.
Operator clicks "Apply changes" — queues a
reload-log-sinksservice command to
osctrl-tls.TLS hot-reload: the
ActionReloadLogSinkshandler now callsSeed(flagParams, ...)beforeBuildExportersForEnvironments. Sincethe reverted row now has
source = "service",seedRow's sync stepoverwrites the config with the current service-config values
(flags, env vars, or YAML). The exporters are then rebuilt from the
freshly synced rows and atomically swapped in.
Seed sinks (
source = "service") do not show the Revert button— there is nothing to revert. The existing
seedRowsync keepsthem up to date on every boot and reload.
Changes
Backend
pkg/logsinks/logsinks.go:RevertToService(id uint) errormethod: flipssourcefrom"db"to"service". No-op if already"service"or legacy"yaml". ReturnsErrSinkNotFoundfor missing rows.cmd/tls/main.go—ActionReloadLogSinkshandler:sinksMgr.Seed(flagParams, ...)call beforeBuildExportersForEnvironmentsso reverted rows get their configre-synced from the current service configuration during the reload.
Previously the reload only read existing DB rows without re-seeding.
cmd/api/handlers/log_sinks.go:LogSinksRevertHandler—POST /api/v1/log-sinks/{id}/revert.Admin-only, audit-logged. Returns the updated row (secrets redacted).
cmd/api/main.go:routes, gated by
serviceConfigEnabled.Frontend
frontend/src/api/log-sinks.ts:revertLogSink(id)function.frontend/src/features/log-sinks/LogSinksPage.tsx:revertMutation(useMutation) callingrevertLogSink.source === 'db'. Styled as a muted secondary action(
text-[color:var(--text-2)] hover:bg-[color:var(--bg-2)]) todistinguish it from Edit (primary) and Delete (danger).
be re-synced from the YAML/flags on the next Apply."
Takes effect on the next Apply."
Tests
pkg/logsinks/logsinks_test.go—TestRevertToService:source is now "service". Verifies revert is idempotent (no-op on
already-service rows). Verifies missing row returns
ErrSinkNotFound.frontend/src/features/log-sinks/LogSinksPage.test.tsx— two new tests:seeds a
source: 'db'row, finds the Revert button, clicks it(with
confirmmocked), verifiesrevertLogSinkwas called withthe right ID.
source: 'service'row, verifies no Revert button is rendered.Validation
Files
Modified (6 files):
pkg/logsinks/logsinks.go—RevertToServicemethodpkg/logsinks/logsinks_test.go— revert testcmd/tls/main.go— re-seed during reloadcmd/api/handlers/log_sinks.go— revert handlercmd/api/main.go— route registrationfrontend/src/api/log-sinks.ts—revertLogSinkfunctionfrontend/src/features/log-sinks/LogSinksPage.tsx— revert buttonfrontend/src/features/log-sinks/LogSinksPage.test.tsx— 2 tests