Repository navigation
fix(cli): kates kyverno apply keeps the kates release's values - #544
Merged
Merged
Conversation
kyverno apply upgraded the kates release with only its kyvernoPolicy.* --set flags, so Helm reset every value deploy had set (Kafka bootstrap and cluster name, networkPolicy.kafka.namespace, rbac.scope=namespace, monitoring, images) to chart defaults; --dry-run rendered the same reset. The upgrade now passes --reset-then-reuse-values: the local chart's defaults first, then the release's user-supplied values, then the policy flags. Plain --reuse-values would also keep the installed chart's old defaults, which breaks templates when the local chart is newer than the release. The flag needs Helm 3.14; CI pins 3.17.0 (versions.env). On a fresh install, upgrade --install takes the install path and the flag has no release to read. Because values are now reused, apply sets each of its opt-in policies (cosign, networkPolicyGeneration, kafka, policyExceptions) to true or false on every run. Otherwise one that an earlier run turned on would stay on, and the preview table and the printed helm command would not show it.
bmscomp
force-pushed
the
fix/kyverno-apply-keeps-values
branch
from
October 29, 2026 12:18
f4b2990 to
e25e64c
Compare
bmscomp
added a commit
that referenced
this pull request
Oct 29, 2026
The scheduler matched schedules with a hand-written matcher that knew only *, */n, a,b, a-b and numbers, while POST and PUT saved any string. So "0 9 * * MON", "@daily" and "0-30/5 * * * *" were saved with a 201 and never fired, day-of-week 7 (Sunday) never matched, */2 in the month field picked February, April, ... instead of January, March, ..., and "0 9 1 * 1" fired only on a 1st that is a Monday, not on either. An expression of 65 to 120 characters passed @SiZe(max = 120) and then failed with a 500 at the 64-character column. The matcher is gone: TestScheduler parses with cron-utils' UNIX definition and matches with ExecutionTime.isMatch on the minute, still in UTC. POST and PUT parse the expression with the same parser and refuse one it can't read with a 400 keyed cronExpression; PUT now also applies the field's @notblank and @SiZe, which is 64 to match the column. Macros such as @daily, six-field expressions and Quartz's ? and L are refused rather than saved. A stored expression that no longer parses throws inside the scheduler's per-schedule try, so it is logged and skipped without stopping the other schedules. Disruption schedules had a copy of the same matcher and saved any non-blank string, so they had the same bugs. DisruptionScheduler now matches with TestScheduler's parser, and the disruption schedules' POST and PUT give the same 400, and refuse an expression wider than its 64-character column. cron-utils already came in through quarkus-scheduler; it is declared now that Kates uses it directly, its version left to the Quarkus BOM. The API reference, CLI reference, the --cron help of kates schedule create and kates disruption schedule create, and their doc entries say which cron the Kates API takes, and four MCP source refs into the edited files are re-pointed. * fix(kyverno): exceptions work on the Kyverno kates installs, and check counts only those Kyverno accepts (#541) * fix(cli): kates kyverno apply keeps the kates release's values (#544) * fix(cli): kates deploy stores the API key only in a context whose API accepts it (#542) * feat(cli): admin-less kind cluster fanon from the deploy gate (#543) * fix(report): errorRate is the share of tasks that failed (#545) * fix(resilience): stop the probes and clean up a fault that never answered (#546) * fix(schedule): a PUT without enabled keeps the schedule's state (#547)
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.
Why
kates kyverno applyranhelm upgrade --install kates charts/kateswith only itskyvernoPolicy.*--setflags. Helm therefore reset every valuekates deployhad set on the kates release (Kafka bootstrap and cluster name,networkPolicy.kafka.namespace,rbac.scope=namespace, monitoring, images) to the chart defaults.--dry-runrendered the same reset. A namespace-scoped install that rankyverno applycame back cluster-scoped and pointed at the default Kafka.What changed
cli/cmd/kyverno_apply.go: the kates upgrade now passes--reset-then-reuse-values, right after--create-namespace. Helm applies the local chart's defaults first, then the release's user-supplied values, then the policy flags.--reuse-values: the chart comes from the local or freshly fetchedcharts/kates, which can be newer than the installed release. Plain--reuse-valueskeeps the release's old full value set and skips new chart defaults, so templates that read new keys break. The repo already recommends--reset-then-reuse-valuesincharts/monitoring/README.md.HELM_VERSION=v3.17.0inversions.env, and Helm 4 supports it too.upgrade --installtakes the install path, so the flag has no release values to read and does nothing.cosign,networkPolicyGeneration,kafka,policyExceptions) are set totrueorfalseon every run. Otherwise a policy that an earlier run turned on would stay on, and neither the preview table nor the printed helm command would show it.cli/cmd/kyverno_test.go:TestKyvernoApplyKeepsReleaseValuesuses the existingkyvernoApplyClusterseam to check two things in the dry-run helm args: they carry--reset-then-reuse-values, and they carrykyvernoPolicy.cosign.enabled=falsewhen--with-cosignis left out. The test fails against the previouskyverno_apply.go.This touches the same
helmArgsblock as #541 (fix/kyverno-exceptions). The added lines are separate, so either PR can merge first and the conflict is trivial.Tests
cd cli && go vet ./...: okcd cli && go test ./...: ok (includes theTestMCPCaveatanchors);go test -count=1 ./cmd -run 'TestKyverno|TestMCPCaveat': okcd cli && golangci-lint run --new-from-rev=$(git merge-base HEAD origin/main) ./...: 0 issuesgofmt -lon the two edited files: cleancd kates && ./mvnw test -Dquarkus.grpc.codegen.skip=true -Dquarkus.http.test-port=0: BUILD SUCCESS, 1747 tests, 0 failures, 3 skippedcd kates && ./mvnw -o -q spotless:check(JDK 25): okOnly CI runs these: integration tests, native image, Kind, Docker, and CodeQL. Nothing was run against a live cluster.
Deliberately not done
kyverno applyinstalls it only when the ClusterPolicy CRD is missing, so there are no release values to lose.