Stéphane Tailland
f5484dd67f
Two at once so the consumer can move without a gap; the old one goes as soon as it has. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Kafka topology
Platform-owned. Topics and accounts on the shared Kafka cluster are administered here, not by the teams that use them.
That is the same reason gateway defaults are here: an ACL is not a team's
decision to make about itself. A team that declares its own KafkaUser grants
its own permissions, and a team that declares its own KafkaTopic sets a
partition count and a retention that the cluster then has to live with. Both are
platform decisions, taken with a view of the whole cluster.
It is also why this is not self-service, and should not be mistaken for it. See "Self-service" below.
What lives here
classic-models.yaml |
the classic-models estate: three topics, one producer account, one consumer account |
The cluster is not here — infra-kafka is a generic, reusable Strimzi
deployment and names no estate. This repo says who may publish what on it.
The events are not here either: their contract belongs to the application
that raises them, in classic-models-api/docs/DOMAIN_EVENTS.md. This repo grants
access; it does not define meaning.
Two things that bite
Every CR goes in the operator's namespace. Strimzi runs with
watchAnyNamespace=false, so a KafkaUser or KafkaTopic created anywhere else
is ignored silently — kubectl apply says created, kubectl get shows it,
and it never gets a status, a Secret, or a line in the operator's log. It looks
exactly like one still being reconciled.
Grant one direction, on one prefix. A producer that can also read every topic exfiltrates every other application's data if it is ever compromised; a consumer that can write can raise an event someone else acts on.
Self-service, when it comes
Not by letting teams declare CRs here or in their own repos. Through an event gateway, which virtualises topics so a consumer is given a contract rather than a broker address and an ACL, and through the developer portal, which socialises those topics the way it already socialises the REST APIs.
Until that exists, this directory is the request queue: a team asks, the platform team writes the entry.