Quickstart — cellule auto-hébergée

Mettez en route une cellule OpenDome qui sert l’API OSL, sans control-plane et sans phone-home. C’est le chemin du self-hoster ; le produit géré/Enterprise ajoute le control-plane central et la console par-dessus exactement les mêmes charts.

Prérequis

Un cluster Kubernetes (kind suffit) avec :
- Un CNI qui applique les NetworkPolicy — Cilium recommandé. Le kindnet par défaut de kind ne l’applique pas. Avec Cilium, installez-le avec --set 'policyCIDRMatchMode={nodes}' ; sans cela, Cilium ignore les règles ipBlock couvrant les IPs de nœud/apiserver et le Postgres bundled reste bloqué à « Setting up primary ». (scripts/cluster-create.sh le fait pour vous sur kind.)
- Un contrôleur Ingress pour atteindre l’API OSL.
- Une StorageClass par défaut (pour l’object store bundled + les PVC Postgres).
- L’opérateur CloudNativePG installé cluster-wide — seulement si vous utilisez le Postgres bundled.
helm ≥ 3.12 et kubectl.

Pour ingress-nginx, installez-le en supprimant tout X-Actor-Roles fourni par le client au niveau de l’edge (défense en profondeur — le moteur ignore ce header en standalone de toute façon) :

helm install ingress-nginx ingress-nginx/ingress-nginx \
  -n ingress-nginx --create-namespace --version 4.11.3 \
  --set-string 'controller.proxySetHeaders.X-Actor-Roles='

Si vous utilisez le Postgres bundled, installez d’abord CloudNativePG :

helm install cnpg cnpg/cloudnative-pg \
  -n cnpg-system --create-namespace --version 0.27.1

Mettre en route la cellule

Le shell de la cellule + l’infra bundled (object store + Postgres).

standard-tenant crée le namespace, une NetworkPolicy deny-all (sans règles allow vers le control-plane), les quotas et — dans le profil standalone — un object store in-namespace (RustFS) et un Postgres CloudNativePG, plus le Secret tenant-object-storage.

# La NetworkPolicy deny-all ne laisse les pods atteindre l’API Kubernetes
# qu’à travers cet allowlist (l’init de CNPG en a besoin). Dérivez les deux
# adresses de VOTRE cluster — sans deviner par distro :
APISERVER_VIP=$(kubectl get svc kubernetes -o jsonpath='{.spec.clusterIP}')
APISERVER_EP=$(kubectl get endpoints kubernetes -o jsonpath='{.subsets[0].addresses[0].ip}')

helm install demo charts/standard-tenant \
  -n tenant-demo --create-namespace \
  --set tenant=demo \
  --set "apiServerEgress.cidrs[0]=$APISERVER_VIP/32" \
  --set "apiServerEgress.endpointCidrs[0]=$APISERVER_EP/32"

Sans valeurs explicites, le chart génère des credentials aléatoires à la première installation et les réutilise lors des upgrades. Récupérez-les à tout moment :

kubectl -n tenant-demo get secret tenant-object-storage -o jsonpath='{.data.accessKey}' | base64 -d
kubectl -n tenant-demo get secret postgres-postgresql   -o jsonpath='{.data.password}'  | base64 -d

Le moteur OSL — la surface de consommation.
Ventana de terminal
```
helm install osl charts/tenant-semantic-api \
  -n tenant-demo \
  --set tenant.id=demo \
  --set ingress.host=osl.tenant-demo.127.0.0.1.nip.io
```
Cela active l’Ingress opt-in et rend le manifest OSL localement à partir des values. Dans le profil standalone, le moteur ne fait pas confiance au header X-Actor-Roles — un appelant via un Ingress public ne peut pas falsifier de rôles. L’accès avec ACL passe par l’émetteur de tokens local : le chart génère un Secret de signature et le moteur valide les tokens Authorization: Bearer HS256.

Vérifiez que la cellule est utilisable via son API — sans control-plane.

HOST=osl.tenant-demo.127.0.0.1.nip.io
curl -fsS "http://$HOST/health"            # {"status":"ok",...}
curl -fsS "http://$HOST/osl/conformance"   # moteur + niveaux de conformance
curl -fsS "http://$HOST/osl/schema"        # manifest compilé (vide tant que vous n’avez pas écrit de facets)

Émettez un token signé localement et faites un appel gouverné.

Les rôles du token pilotent l’ACL — les facets les honorent server-side.
Ventana de terminal
```
TOKEN=$(scripts/osl-token.sh demo --roles analyst)
curl -fsS -H "Authorization: Bearer $TOKEN" "http://$HOST/osl/schema"
```
Un token invalide ou expiré est un 401 net (E3001). Le moteur ne dégrade jamais en silence un token cassé vers « anonyme ».

Si cela renvoie 200 sans que le namespace opendome-system existe, la cellule est utilisable en standalone. Exécutez scripts/oss-gate.sh pour l’affirmer de bout en bout.

Couches optionnelles

Jambe structurée (Trino + Nessie + Iceberg) — charts/lakehouse. Par défaut, des endpoints in-namespace avec des credentials du Secret tenant-object-storage ; nécessite le Postgres bundled/externe de l’étape 1.
API de Config (allowlist / pipeline / discovery) — charts/tenant-config. Déjà standalone : utilise le Postgres propre de la cellule + une API directe GET/PUT /config/{key}.
Ingest / orchestration — charts/dagster. Par défaut : pas de callbacks vers le control-plane, pas de télémétrie upstream, les Jobs tournent dans ce namespace.

Reconstruire les images dans votre propre registry

Les charts publiés épinglent les images par digest immuable (image.digest: sha256:…), qui prime sur le tag. Ce digest identifie l’image publiée d’OpenDome — il n’a aucun sens dans un autre registry. Si vous reconstruisez les images de la cellule dans votre propre registry, effacez le digest livré sous peine de voir chaque pod tomber en ImagePullBackOff :

helm install osl charts/tenant-semantic-api \
  --set image.repository=myreg.example/tenant-semantic-api \
  --set image.digest=""          # ← REQUIS lorsque vous changez le repository

Faites de même pour tenant-mgmt-api.runnerImages.*. Si vous tirez les images publiées d’OpenDome, laissez le digest tel que livré et faites-en un cosign verify.

Charger de vraies données

Pour servir de vrais retrievals : créez le bucket (tenant-demo) dans votre object store, écrivez des facets OSL (YAML UnstructuredFacet / JointEntity sous le manifest.facets du moteur) et ingérez des datasets Lance vers s3://tenant-demo/lance. Voir Concepts pour le modèle du manifest et la référence de l’API pour savoir comment le retrieval est appelé.