chore(deps): update kro to v0.9.4 - #180
Open
renovate[bot] wants to merge 11 commits into
Open
renovate[bot] wants to merge 11 commits into
renovate[bot] wants to merge 11 commits into
Conversation
Contributor
Author
ℹ️ Artifact update noticeFile name: test/e2e/go.modIn order to perform the update(s) described in the table above, Renovate ran the
Due to Go's usage of Minimal Version Selection (MVS), these packages have been updated to the minimum version available, so will still abide by Details:
|
renovate
Bot
force-pushed
the
renovate/kro
branch
5 times, most recently
from
September 22, 2026 19:27
2cfa0a2 to
9c9a64a
Compare
guewa
enabled auto-merge (squash)
September 22, 2026 19:40
guewa
previously approved these changes
Sep 22, 2026
renovate
Bot
force-pushed
the
renovate/kro
branch
from
September 24, 2026 03:15
9c9a64a to
e2b1ac6
Compare
- Taskfile: add --copy-resources flag to push-component.py invocations (script now requires explicit mode: --copy-resources or --copy-local-resources) - build-component.py: clarify comment to reference open-component-model/ocm v0.48+ CLI Signed-off-by: Michael Sprauer <Michael.Sprauer@sap.com>
Contributor
Author
Edited/Blocked NotificationRenovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR. You can manually request rebase by checking the rebase/retry box above. |
kro v0.9.4 has a regression (kubernetes-sigs/kro#1448) where includeWhen expressions referencing only static schema fields (schema.spec.*) are classified as data-pending and never resolve when the instance does not explicitly set those fields (even when a default is defined). The remote-observability RGD uses includeWhen: [${schema.spec.certManager.enabled}] on 8 resources. When the ObservabilityStack creates a RemoteObservability CR without explicitly setting certManager.enabled, kro v0.9.4 fails to evaluate these includeWhen conditions, leaving the instance stuck and never ready. Fix: explicitly pass certManager.enabled: true in the RemoteObservability template so the field is always present in the child CR spec. Signed-off-by: Michael Sprauer <Michael.Sprauer@sap.com>
….9.4 kro v0.9.4 takes longer to reconcile the full ObservabilityStack (~25-30min) compared to v0.9.3 (~14min). The additional time is due to more HelmDeployment resources being reconciled on workload clusters (cert-manager, otel-operator, otel-collector-resource) now that certManager.enabled is explicitly set. The 20-minute timeout was sufficient for v0.9.3 but not for v0.9.4. Signed-off-by: Michael Sprauer <Michael.Sprauer@sap.com>
…status kro v0.9.4 adds an 'internal.kro.run/apply-order' annotation to all managed resources via server-side apply on every reconcile. This bumps metadata.generation on HelmDeployment resources, while status.observedGeneration (updated by the HelmDeployment controller) lags behind. The result: the generation equality check otelOperatorHelmDeployment.status.observedGeneration == otelOperatorHelmDeployment.metadata.generation is permanently false in kro v0.9.4, preventing RemoteObservability.status.ready from ever becoming true, which blocks ObservabilityStack.status.ready. Fix: use only status.phase == 'Ready' as the readiness signal, which is stable and not affected by kro's annotation management. Also revert the 35m test timeout to 20m since the actual readiness delay was caused by this generation drift, not by genuine extra work. Signed-off-by: Michael Sprauer <Michael.Sprauer@sap.com>
Temporary diagnostic to understand why status.ready never becomes true in kro v0.9.4. Will be removed after the root cause is identified. Signed-off-by: Michael Sprauer <Michael.Sprauer@sap.com>
Signed-off-by: Michael Sprauer <Michael.Sprauer@sap.com>
kro v0.9.4 introduced stricter CEL value handling (PR #1346): accessing individual bytes fields from Kubernetes Secret.data (e.g. data["tls.crt"]) returns a CEL bytes type, which can no longer be used directly in resource templates. The error is: unsupported type: bytes value cannot be used directly in a resource template; encode it explicitly, e.g. base64.encode(...) kro v0.9.3 silently accepted bytes in templates (converting []byte directly); v0.9.4 rejects it, causing remoteClientCertSecret creation to fail with an error, preventing RemoteObservability from ever reaching status.ready=true. Fix: wrap the three Secret.data field accesses with base64.encode() to produce the base64 strings that Kubernetes Secret.data expects. Also remove temporary diagnostic logging added during investigation. Signed-off-by: Michael Sprauer <Michael.Sprauer@sap.com>
kro v0.9.4 rejects bytes values in resource templates (EnsureJSONSafe check, PR #1346). The remoteClientCertSecret merged data from two secrets using individual field access (Secret.data["tls.crt"]), which returns CEL bytes type. Using base64.encode() to fix the runtime error causes a type-check failure (expected bytes but got string). Solution: eliminate the merged secret entirely. Instead, mount the two source secrets directly as separate volumes in the OTel collector: - observabilityClientCertSecret → /etc/otel/certs/client (tls.crt, tls.key) - otlpLogsCertSecret → /etc/otel/certs/ca (tls.crt as CA cert) This avoids any per-field bytes access while preserving the cert data needed for mutual TLS. The secretsToCopy list is updated to copy both source secrets to the workload cluster. Signed-off-by: Michael Sprauer <Michael.Sprauer@sap.com>
kro v0.9.4 introduced two breaking changes affecting remote-observability:
1. metadata.generation drift: kro v0.9.4 adds an apply-order annotation to
all managed resources on every reconcile, bumping metadata.generation.
The status expressions compared observedGeneration == metadata.generation,
which was never stable. Fixed by checking only status.phase == 'Ready'.
2. Bytes values in templates (kro v0.9.4 PR #1346): accessing individual
fields from Secret.data (e.g. data["tls.crt"]) returns CEL bytes type
which can no longer be used directly in resource templates (EnsureJSONSafe
now rejects []byte). Using base64.encode() fails type-check (expected bytes
but got string).
Fixed by replacing the merged remoteClientCertSecret (which needed individual
bytes field access) with two separate secrets using whole-map data copy:
- clientCertSecretCopy: data: ${observabilityClientCertSecret.data}
- caCertSecretCopy: data: ${otlpLogsCertSecret.data}
Whole-map access uses convertMap's fast-path (raw Go map, no bytes decode).
The OTel collector mounts both secrets at separate paths:
- /etc/otel/certs/client/ (tls.crt, tls.key)
- /etc/otel/certs/ca/ (tls.crt as CA cert)
Signed-off-by: Michael Sprauer <Michael.Sprauer@sap.com>
…template Kubernetes applies the CRD default (enabled: true) when the CR is created, so setting it explicitly is redundant. Additionally, having cert-manager explicitly installed on workload clusters increased reconciliation load, causing the opencontrolplane_controlplane Prometheus metric to take longer to appear (beyond the 5-minute test timeout). Signed-off-by: Michael Sprauer <Michael.Sprauer@sap.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
2 participants
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.
This PR contains the following updates:
v0.9.3→v0.9.40.9.3→0.9.4Release Notes
kubernetes-sigs/kro (github.com/kubernetes-sigs/kro)
v0.9.4Compare Source
What's Changed
New Contributors
Full Changelog: kubernetes-sigs/kro@v0.9.3...v0.9.4
Configuration
📅 Schedule: (UTC)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about these updates again.
This PR was generated by Mend Renovate. View the repository job log.