fix(charts): explicit lenient probe tolerances (sse-proxy, otel wrappers) + Quantity schema typing - #32
Merged
Merged
Conversation
…ers) + Quantity schema typing Two org-standard sweeps in one pass over this repo's charts: 1) Probe tolerances. The Kubernetes probe defaults (timeoutSeconds: 1, failureThreshold: 3) kill HEALTHY pods under CPU contention: a slow-but-alive health reply counts as a failure and the resulting restart storm worsens the contention. Per the org standard (precedent: the chart-inspector block in the core-provider chart, authn PR #13 and the sibling sweep PRs): - livenessProbe: timeoutSeconds: 5, failureThreshold: 6 — lenient, so only a truly dead process is restarted (sse-proxy: 10s x 6 = 60s window; otel wrappers: implicit 10s default x 6 = 60s window). - readinessProbe: timeoutSeconds: 5, failureThreshold: 3 — endpoint removal stays prompt, but load alone must not flap it. krateo-sse-proxy gets this directly in templates/deployment.yaml (probes are hardcoded there, existing periodSeconds kept). The two otel-collector wrappers get it via values passthrough to the upstream opentelemetry-collector chart 0.158.1, whose templates/_pod.tpl renders exactly these keys; the wrappers' values.schema.json is extended to type the new livenessProbe/readinessProbe keys. Resources untouched; no probes added to containers that have none (krateo-observability ships no workload templates of its own). 2) Quantity schema typing scan. values.schema.json fields for Kubernetes Quantities (cpu/memory/storage) typed as bare integer/number propagate into crdgen-generated composition CRDs and break the krateo-composition-version MutatingAdmissionPolicy typed conversion on Quantity strings (krateo-core-provider#66; snowplow had it, fixed in snowplow PR #140). Scanned all four charts' schemas: CLEAN — every cpu/memory/persistence-size field is already typed "string" (the only integer size-like fields, max_log_size/send_batch_size, are OTel collector config counts, not k8s Quantities). No changes needed. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LJsLqtryCgWwEt8FnPE1se
braghettos
added a commit
that referenced
this pull request
Aug 7, 2026
krateo-sse-proxy 0.1.6 -> 0.1.7, otel-collector-deployment 0.3.3 -> 0.3.4, otel-collector-daemonset 0.1.5 -> 0.1.6. PR #32 shipped the template/schema changes without bumping the literal chart versions. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LJsLqtryCgWwEt8FnPE1se
braghettos
added a commit
that referenced
this pull request
Aug 7, 2026
Convert the bundle to the invariant OKF file set (ChartRepo index): thin
README skeleton, docs/{index,overview,usage,configuration,api,examples,
release,log}.md + rewritten docs/llms.txt, and a runnable
examples/observability-composition. Every claim re-derived from the four
charts (rendered via helm template with vendored deps) and the installer
component pins; docs/wiring.md and docs/crds.md folded into
configuration.md / api.md.
Divergences fixed while re-verifying:
- compositiondefinition.yaml pointed at the nonexistent OCI artifact
charts/observability@0.1.8 -> charts/krateo-observability@0.1.11 (the
release workflow publishes by chart name; verified against GHCR).
- README/old docs still described the pre-migration layout (kagent/ agent
chart, CHART_VERSION placeholder versioning, stale image tags 1.0.0,
fullnameOverride krateo-observability, the inert http-handlers ConfigMap
as if live) — all rewritten to current source.
- The stale template-comment claim that upstream emits a
krateo-clickstack-app Service corrected in docs: the rendered upstream
Service is krateo-clickstack (3000/app, 4320/opamp).
CI: lint.yaml now also calls the shared lint-docs reusable
(krateo-platformops/.github). Chart values/templates untouched (PR #32
owns the probe changes).
Claude-Session: https://claude.ai/code/session_01LJsLqtryCgWwEt8FnPE1se
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.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
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.
Applies the org probe-tolerance standard to this repo's charts and runs the Quantity schema-typing scan, in one PR.
Problem 1: default probe tolerances kill healthy pods under CPU contention
The Kubernetes probe defaults (
timeoutSeconds: 1,failureThreshold: 3) mean a slow-but-alive health reply counts as a probe failure — under CPU contention healthy pods get liveness-killed, and the resulting restart storm worsens the contention. The org standard (precedent: the chart-inspector block in the core-provider chart, authn PR #13 and the sibling sweep PRs merged with it):timeoutSeconds: 5,failureThreshold: 6— lenient, so only a truly dead process is restarted.timeoutSeconds: 5,failureThreshold: 3— endpoint removal stays prompt, but load alone must not flap it.periodSecondskept; resources untouched; no probes added where none exist.Per-chart changes
krateo-sse-proxytemplates/deployment.yaml(probes hardcoded there)t=1, fail=3, per=10(defaults) →t=5, fail=6, per=10= 60s windowt=1, fail=3, per=5(defaults) →t=5, fail=3, per=5otel-collector-deploymentvalues.yamlpassthrough to upstreamopentelemetry-collector0.158.1 (templates/_pod.tplrenders these keys)t=5, fail=6, implicitper=10= 60s windowt=5, fail=3, implicitper=10otel-collector-daemonsett=5, fail=6, implicitper=10= 60s windowt=5, fail=3, implicitper=10Both wrappers'
values.schema.jsonare extended to type the newlivenessProbe/readinessProbekeys (matching the upstream chart's own schema key set). Rendering was verified end-to-end through the upstream subchart: the tolerances land in the rendered Deployment/DaemonSet pod specs.krateo-observabilityships no workload templates of its own (only Services + a Secret; pods come from the upstream clickstack subchart), so per the standard nothing was added there.Problem 2: Quantity fields typed as integer/number in values.schema.json
Bare
integer/numbertyping on Kubernetes Quantity fields (cpu/memory/storage) propagates into crdgen-generated composition CRDs and breaks the krateo-composition-version MutatingAdmissionPolicy typed conversion on Quantity strings (krateo-core-provider#66; snowplow had it, fixed in snowplow PR #140).Scan result: CLEAN. All four charts' schemas already type every cpu/memory/persistence-size field as
"string". The only integer size-like fields (max_log_size,send_batch_size) are OTel collector config counts, not k8s Quantities. No changes needed.🤖 Generated with Claude Code
https://claude.ai/code/session_01LJsLqtryCgWwEt8FnPE1se