Skip to content

ragleap-ops v0.2.0

Choose a tag to compare

View all tags
@antonyrag antonyrag released this 31 Aug 07:40
· 42 commits to main since this release
ragleap-ops-v0.2.0
dc5fe29
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Added

  • Helm chart (helm/ragleap-ops/) wrapping all four k8s/ manifests (db, app, voice, neo4j) with real configurable values.yaml — image tags, resource limits, storage sizes, probe timings, credentials.
  • Real database schema (db/schema.sql) is packaged into the chart via Helm's .Files.Get, copied verbatim from the repo's real schema file, not reproduced from memory.

Fixed

  • neo4j's liveness probe had no explicit failureThreshold in the Helm template (unlike the raw k8s manifest, which was already correctly set) — defaulted to Kubernetes' built-in 3, too tight for JVM startup under CPU contention. Found via live helm install/helm upgrade testing on a real kind cluster (not caught by helm lint or helm template, since those don't exercise runtime behavior). Fixed to match the readiness probe's more generous timing (initialDelaySeconds: 60, failureThreshold: 6).

Verified

  • All four services (db, app, voice, neo4j) independently reached 1/1 Running with zero restarts for extended periods (60+ minutes) on a real kind cluster via helm install.
  • Added explicit resources.requests/limits for neo4j (512Mi memory request, 1Gi limit; CPU tuned to 50m during testing) after live testing on this session's VPS surfaced real host-level CPU/memory contention (the test VPS runs several other production services concurrently) — this is a permanent, worthwhile chart improvement, not a workaround specific to this host.

Known limitations

  • Full 4-service stack was demonstrated stable in bounded windows (60+ min) on a resource-constrained single-node test host that was also running unrelated production services. Extended (multi-hour) concurrent-stack stability was not verified on this specific host due to genuine host-level memory/CPU exhaustion (swap fully exhausted at points during testing) — not a chart defect, but an honest scope boundary on what was tested. A dedicated cluster (not sharing a host with other production workloads) is expected to have materially more headroom.
  • CPU resource values (cpu: 50m for neo4j) were tuned against a heavily constrained single-vCPU-allocatable test node and should be reviewed against real target-cluster capacity before production use, not assumed as a universal recommendation.
  • Same limitations as v0.1.0 still apply: app-env-secret.yaml/db-schema-configmap.yaml's real content are environment-specific and not shipped; PVC storage sizes remain placeholder defaults.
Assets 2
Loading