Repository navigation
Normalize --namespace, validate namespace case, fix error messages/CRD text, stop echoing dockerconfigjson parse errors - #752
Merged
joaopapereira merged 5 commits intoOct 9, 2026
Conversation
aroradaman
reviewed
Oct 5, 2026
sameerforge
force-pushed
the
fix/namespace-handling-error-messages-credential-echo
branch
from
October 7, 2026 06:50
bbcfebf to
4b93559
Compare
…case Namespace names are RFC 1123 labels (always lowercase), but the --namespace flag used the operator-supplied value verbatim. The value is used as a controller-runtime cache key, and a mixed-case value would fail to watch anything with no error reported. Address reviewer feedback by changing from silent normalization to early validation with clear error messaging: - Update the flag description to clarify the lowercase requirement - Change normalizeNamespace() to return (string, error) and validate instead of silently lowercasing the input - Error out early with a clear message: "namespace must be lowercase (RFC 1123 DNS label), got 'X'" — matching the ytt template validation - Updated tests to verify both valid and invalid namespace values This ensures early failure with a clear error message, consistent with the ytt template behavior and the RFC 1123 specification for namespace names. Signed-off-by: Nikhil Sagotiya <nikhil.sagotiya@broadcom.com>
…ing messages Follow-up to the earlier error-message pass. Only message text changes; no logic or return values change. - status condition no longer leaks a Go identifier: "Expected secret to have type=corev1.SecretTypeDockerConfigJson, but did not" now names the real type 'kubernetes.io/dockerconfigjson' - "PEM formatted block" -> "a PEM-formatted block" (certificate and key) - "got err" -> "got error"; "serviceaccount" -> "service account" - consistent lowercase "input resources"; consistent single-quote style in the SecretExport validation messages, which now name the actual spec fields - token refresh error reads "token for service account 'ns/name'"; the cache key itself is unchanged - CRD descriptions (kubectl explain): "InputResource is references ... a identifying" and "dynamic valid" fixed in the Go comments and crds.yml - hack scripts: "non zero" -> "non-zero" with a clearer explanation, and punctuation in the e2e note Tests that assert the old strings are updated. Signed-off-by: Nikhil Sagotiya <nikhil.sagotiya@broadcom.com>
controller-gen copies the description of corev1.LocalObjectReference.Name verbatim, including an upstream "TODO: Add other useful fields. apiVersion, kind, uid?" note, which then shows up in kubectl explain for the SecretTemplate status.secret and Certificate spec.caRef fields. Strip it in hack/crd-overlay.yml so that regenerating the CRDs does not bring it back, and apply the same change to the committed crds.yml. Checked by applying the overlay to the previous crds.yml: exactly those two description lines change. Signed-off-by: Nikhil Sagotiya <nikhil.sagotiya@broadcom.com>
… is invalid NewCombinedDockerConfigJSON included the raw json.Unmarshal error in its message. encoding/json syntax errors echo the offending input character, and this data holds registry credentials, so a secret that is not valid JSON could leak its first character into the returned error, which is written to the resource status and the controller logs. Return a generic "data is not valid dockerconfigjson" message instead. The reconcile still fails the same way. Adds a test asserting that no part of unparseable input appears in the error. Signed-off-by: Nikhil Sagotiya <nikhil.sagotiya@broadcom.com>
sameerforge
force-pushed
the
fix/namespace-handling-error-messages-credential-echo
branch
from
October 7, 2026 06:52
4b93559 to
3026cfc
Compare
…tions - Fix comma splice in CRD reason descriptions: "Unique, this should be..." → "Unique; this should be..." - Add hyphen to compound adjective: "machine understandable" → "machine-understandable" - Fix redundant "error:" suffix in test error messages - kapp.go: Remove redundant "error:" suffix in execution error message - kubectl.go: Remove redundant "error:" suffix in execution error message These changes improve message clarity and comply with grammar and formatting standards. Signed-off-by: Sameer Khan <sameer.khan@broadcom.com>
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.
What this PR does
A small set of robustness and message-quality fixes, split into four independent commits so they can be reviewed (or dropped) separately.
1.
fix: normalize --namespace flag and validate namespace value is lowercaseNamespace names are RFC 1123 labels, so always lowercase, but two places used the operator-supplied value verbatim:
--namespaceflag (cmd/controller/main.go): the value is used as a controller-runtime cache key. A mixed-case value made the controller watch nothing and reconcile nothing, with no error reported. It is now lowercased and trimmed once, right after flag parsing (newnormalizeNamespacehelper plus a unit test). The shipped Deployment does not pass this flag, so this only affects manual or custom runs.package-bundle ytt config (
config/package-bundle/config/deployment.yml):data.values.namespacewas substituted straight intoNamespace.metadata.name. A mixed-case value rendered fine and only failed later at apply time with an API-server validation error. The config now fails at render time with a clear message:Validation Error: namespace must be lowercase (RFC 1123 DNS label), got 'SecretGen-Sys'Valid (lowercase) values are unaffected: the default render is byte-identical to before.
2.
fix(error-messages): correct grammar, quoting and wording in user-facing messagesFollow-up to the earlier error-message pass. Message text only; no logic or return values change.
Expected secret to have type=corev1.SecretTypeDockerConfigJson, but did notnow readsExpected secret to have type 'kubernetes.io/dockerconfigjson', but it does not.PEM formatted blockbecomesa PEM-formatted block(certificate and private key).got errbecomesgot error;serviceaccountbecomesservice account.input resources, and consistent single-quote style in theSecretExportvalidation messages, which now name the actual spec fields.token for service account 'ns/name' .... The token cache key itself is unchanged.kubectl explain:InputResource is references ... a identifyinganddynamic validare fixed in the Go comments and incrds.yml.non zerobecomesnon-zerowith a clearer explanation, and the e2e note gets proper punctuation.The tests that assert the old strings are updated.
3.
fix(crds): strip unresolved "TODO" note from generated CRD descriptionscontroller-gencopies the description ofcorev1.LocalObjectReference.Nameverbatim, including an upstreamTODO: Add other useful fields. apiVersion, kind, uid?note, which then shows up inkubectl explainforSecretTemplatestatus.secretandCertificatespec.caRef.hack/crd-overlay.ymlnow strips it so regenerating does not bring it back, andcrds.ymlgets the same change. I checked the overlay against the previouscrds.yml: exactly those two description lines change.4.
fix(sharing): do not echo parser error when a dockerconfigjson secret is invalidNewCombinedDockerConfigJSONput the rawjson.Unmarshalerror in its message.encoding/jsonsyntax errors echo the offending input character, and this data holds registry credentials, so a secret that is not valid JSON could leak its first character into the returned error, which ends up in the resource status and the controller logs. It now returnsdata is not valid dockerconfigjson. Reconcile still fails the same way. A new test asserts that no part of unparseable input appears in the error.Testing
golangci-lintv2.12.2 (the version CI pins) with the repo config: 0 issues.hack/verify-no-dirty-files.sh(what CI runs first:go fmt, vendor, tidy, build, test compile, ytt render): passes and leaves the tree clean.go test ./pkg/... ./cmd/...: pass, also withGODEBUG=fips140=onlyfor the generator, sharing and satoken packages.namespacevalue is rejected with the message above.hack/test-all.sh), since it needs minikube/kapp. I'm relying on the CI job for that.Notes for reviewers
config/package-bundle/config/crds.ymlwas edited by hand for four description lines (two typos, twoTODOstrips). Runninghack/gen-crds.shwith the currently vendoredcontroller-genrewrites about 200 lines of that file (descriptions reflowed, some fields reordered). That mismatch already exists ondevelopand is not caused by this PR, and CI does not run the generator. It may be worth a separate PR that regenerates the CRDs.