Data Services Naming Standards

Purpose: For contributors, provides naming conventions for data services products, platforms, artifacts, and APIs.

Overview

These naming standards apply to all data services in the openCenter portfolio. They are derived from ADR-004 and ensure consistency across documentation, GitOps manifests, CLI output, and customer-facing materials.

Product Names

Use the full product name in documentation, sales materials, and customer-facing UI. Do not abbreviate.

Product	Correct Name	Incorrect
Managed Kafka	openCenter Managed Kafka	OC Kafka, Managed Kafka (without prefix), Strimzi Kafka
Managed PostgreSQL	openCenter Managed PostgreSQL	OC Postgres, Managed PG, PostgreSQL Service

When referring to the product after first use in a document, "Managed Kafka" or "Managed PostgreSQL" is acceptable as a short form. Do not use "Kafka" alone when referring to the openCenter service — it is ambiguous with upstream Apache Kafka.

Blueprint Names

Blueprints are versioned deployment specifications. Use kebab-case for blueprint identifiers.

Pattern	Example
managed-<service>-v<major>	managed-kafka-v1
managed-<service>-v<major>	managed-postgresql-v1

Blueprint names appear in:

• GitOps repository paths
• FluxCD Kustomization names
• CLI output (opencenter cluster commands)
• Release tags

Namespace Pattern

Data services use the data-<service> namespace pattern:

Service	Namespace
Kafka	data-kafka
PostgreSQL	data-postgresql
Schema Registry	data-schema-registry

The namespace is created by the service blueprint and should not be shared with other workloads. One namespace per service instance.

CRD Naming

CRD names follow the upstream operator conventions. Do not rename or alias them.

Operator	CRDs
Strimzi	Kafka, KafkaTopic, KafkaUser, KafkaConnect, KafkaMirrorMaker2
postgres-operator	postgresql, postgresqlbackup (operator-specific — confirm with selected operator)

When referencing CRDs in documentation, use the exact API kind (e.g., KafkaTopic, not "Kafka Topic" or "kafka topic").

Kubernetes Resource Names

Resource Type	Pattern	Example
Kafka cluster CR	<environment>	production, staging
KafkaTopic	<domain>-<entity> or <team>-<entity>	orders, payments-events
KafkaUser	<app>-<role>	billing-producer, analytics-consumer
ServiceMonitor	kafka-brokers	kafka-brokers
ConfigMap (metrics)	kafka-metrics	kafka-metrics
Secret (client certs)	Auto-generated by Strimzi, matches KafkaUser name	billing-producer

GitOps Repository Paths

Data service manifests live under the managed-services/ directory in customer overlays:

applications/overlays/<cluster>/
├── managed-services/
│   ├── kafka/
│   │   ├── kustomization.yaml
│   │   ├── kafka-cluster.yaml
│   │   ├── kafka-metrics-config.yaml
│   │   └── topics/
│   │       ├── orders.yaml
│   │       └── events.yaml
│   └── postgresql/
│       ├── kustomization.yaml
│       └── postgresql-cluster.yaml

FluxCD Resource Names

Resource	Pattern	Example
GitRepository (operator source)	opencenter-<service>-operator	opencenter-strimzi-operator
Kustomization (operator)	<service>-operator	strimzi-operator
Kustomization (service)	managed-<service>	managed-kafka

Helm Release Names

When data services use Helm charts (e.g., the Strimzi operator chart):

Release	Namespace	Chart
strimzi-operator	data-kafka	strimzi/strimzi-kafka-operator

Docker Image Tags

Images are pinned to specific versions and mirrored through Harbor. Do not use latest or mutable tags.

Image	Tag Pattern	Example
Strimzi operator	<strimzi-version>	quay.io/strimzi/operator:0.40.0
Kafka broker	<strimzi-version>-kafka-<kafka-version>	quay.io/strimzi/kafka:0.40.0-kafka-3.7.0

In air-gap environments, these images are available from the Harbor mirror at <harbor-host>/strimzi/operator:0.40.0.

Documentation References

When linking between data services docs, use relative paths:

See [Deploying Kafka](./kafka-deploy.md) for provisioning steps.

When referencing ADR-004 from documentation:

This follows the blueprint model defined in ADR-004.