Repository navigation
fix(detect): the Strimzi operator lookup is not thrown off by "error" in any deployment's JSON - #394
Merged
Merged
Conversation
… in any deployment's JSON Detect lists every deployment in the cluster to find the Strimzi operator, and fell back to namespace kafka whenever that JSON contained the text "error" or "Forbidden". Any deployment with an argument like --log-level=error matched, so an operator in strimzi-system went unseen, detect reported Strimzi not running, and kates deploy and kates auto acted on that. The fallback now runs on what kubectl says, an error or no output, the way a refusal arrives. TestGetStrimziStatus_FindsTheOperatorBesideAnErrorLogLevel lists an ingress controller with --log-level=error beside the operator in strimzi-system.
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
1 participant
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.
Item 1.7a of the CLI performance and stability plan (finding F18, first half). Independent of the other Wave 1 PRs, 1.7b included.
Why
Detect feeds
kates autoand the preflight and generated values ofkates deploy. To find the Strimzi operator it lists every deployment in the cluster,kubectl get deployment -A -o json. On main (6f4cf61,cli/pkg/detect/collector.go:556) it falls back to-n kafkawhenever that output contains the texterrororForbidden.The output is the JSON of every deployment. One deployment with an argument like
--log-level=error, which is common for ingress controllers and operators, sends the lookup to namespacekafka. An operator instrimzi-systemthen goes unseen, and detect reports Strimzi not running.Changes
cli/pkg/detect/collector.go: the fallback runs onerr != nilor empty output only.OSExecutor.Execreturns an error carrying kubectl's stderr when the command fails, so a cluster-scope refusal (Forbidden) still falls back.Tests
Added
TestGetStrimziStatus_FindsTheOperatorBesideAnErrorLogLevel. It lists an ingress controller with--log-level=errorbesidestrimzi-cluster-operatorinstrimzi-system, and expects the operator found there with its image.On main's
collector.gothe test fails withRunning false in "".Run locally, passing:
cd cli && go test ./...,go test -race ./pkg/detect,go vet ./....golangci-lint run --new-from-rev=origin/main ./...: 0 issues.scripts/check-cli-style.shandscripts/check-cli-compat.sh: OK.cli/**triggers (Build & Test): this PR touches nothing underkates/../mvnw teston main'skates/tree ran 1,254 tests with 0 failures and 0 errors, once for all of Wave 1.Skipped locally:
govulncheck, asgo.modis unchanged.CI only:
./mvnw verifywith the*ITtests, the Kind and Docker jobs, CodeQL and Trivy.