History

hatiyildiz 9b3211fdee docs(pass-14): banners on workflow / analytics / metering / chaos / valkey (7 components) Seven more Application Blueprint banners landed: - temporal (§4.3): durable workflow orchestration; bp-fabric. - flink (§4.3): stream + batch processing; bp-fabric. - debezium (§4.2): CDC into Strimzi/Kafka; bp-fabric pipeline source. - iceberg (§4.4): open table format on MinIO + archival S3. - openmeter (§4.8): API metering for bp-fingate. - litmus (§4.9): chaos engineering required by DORA / NIS2. - valkey (§4.1): banner explicitly states NOT a Catalyst control- plane component — control plane uses NATS JetStream KV per ARCHITECTURE §5 / GLOSSARY event-spine. Valkey is Application-tier caching only. This is the disambiguation that PLATFORM-TECH-STACK §1 establishes ("same upstream technology can serve in multiple categories") — pinned in the per-component README so it can't be misread. VALIDATION-LOG: Pass 14 entry added. Refs #37	2026-04-27 21:52:03 +02:00
..
README.md	docs(pass-14): banners on workflow / analytics / metering / chaos / valkey (7 components)	2026-04-27 21:52:03 +02:00

hatiyildiz 9b3211fdee docs(pass-14): banners on workflow / analytics / metering / chaos / valkey (7 components)

Seven more Application Blueprint banners landed:

- temporal (§4.3): durable workflow orchestration; bp-fabric.
- flink (§4.3): stream + batch processing; bp-fabric.
- debezium (§4.2): CDC into Strimzi/Kafka; bp-fabric pipeline source.
- iceberg (§4.4): open table format on MinIO + archival S3.
- openmeter (§4.8): API metering for bp-fingate.
- litmus (§4.9): chaos engineering required by DORA / NIS2.
- valkey (§4.1): banner explicitly states NOT a Catalyst control-
  plane component — control plane uses NATS JetStream KV per
  ARCHITECTURE §5 / GLOSSARY event-spine. Valkey is Application-tier
  caching only. This is the disambiguation that PLATFORM-TECH-STACK
  §1 establishes ("same upstream technology can serve in multiple
  categories") — pinned in the per-component README so it can't be
  misread.

VALIDATION-LOG: Pass 14 entry added.

Refs #37

2026-04-27 21:52:03 +02:00

README.md

docs(pass-14): banners on workflow / analytics / metering / chaos / valkey (7 components)

2026-04-27 21:52:03 +02:00

README.md

Litmus Chaos

Chaos engineering experiments for Kubernetes. Application Blueprint (see docs/PLATFORM-TECH-STACK.md §4.9 — Chaos engineering). Used to validate Catalyst's resilience guarantees (failover-controller behavior under network partition, OpenBao DR promotion, k8gb endpoint removal) — see docs/SRE.md for the resilience model. Required by some compliance regimes (DORA, NIS2) as evidence of resilience testing.

Category: Chaos Engineering | Type: Application Blueprint

Overview

Litmus provides chaos engineering experiments for Kubernetes workloads. Banks and regulated environments need proof of resilience — Litmus enables automated chaos testing as part of CI/CD pipelines and compliance validation.

Key Features

Pre-built chaos experiments (pod-kill, network-latency, disk-fill)
ChaosHub for experiment catalog
GameDay orchestration
Resilience scoring
CI/CD integration via Gitea Actions

Integration

Component	Integration
Grafana	Chaos experiment observability
Kyverno	Policy-based chaos boundaries
Gitea Actions	Automated chaos in CI/CD
Failover Controller	Validate failover behavior

Deployment

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: litmus
  namespace: flux-system
spec:
  interval: 10m
  path: ./platform/litmus
  prune: true

Part of OpenOva