Upgrade-Guide r3.5.0

Dieser Guide richtet sich an Betreiber, die eine OctoMesh-Installation von r3.4.x auf r3.5.0 heben. Was neu ist, fassen die Release Notes r3.5.0 zusammen.

Upgrade nur in eine Richtung

Der Communication Controller migriert beim Start jeden Tenant von System.Communication 3.x auf 4.x. Es gibt keinen Downgrade-Pfad: Code aus r3.4.x kann 4.x-Daten nicht lesen. Der einzige Weg zurück ist das Wiederherstellen des Datenbank-Backups, das vor dem Upgrade erstellt wurde; alles, was nach der Migration geschrieben wurde, geht dabei verloren. Beginnen Sie nicht ohne geprüftes Backup.

Was sich ändert

Bereich	Änderung	Nötige Aktion
CK-Modelle	`System.Communication` 3.x → 4.6.0, `System.Ai` 3.x → 4.3.0	keine, die Migration läuft automatisch
Daten	`Pool`-Entitäten werden zu `DeploymentSite`; `Manages`/`ManagedBy`-Kanten werden zu `Hosts`/`HostedBy`	nach dem Upgrade prüfen
Kubernetes	CRD `CommunicationPool` (`v1alpha1`) wird durch `DeploymentSite` (`v1`) ersetzt; keine Konvertierung	neue CRD installieren, jeden Site neu deployen, alte Resources und alte CRD löschen
Helm-Werte des Operators	`autoManagePools`, `poolNamespace`, `defaultPoolName` umbenannt	jede Values-Datei und jedes Overlay anpassen
Helm-Werte des Core-Charts	neue Werte für Hub-Autorisierung und SECRET-Key-Ring	keine; sie sind inaktiv, bis sie konfiguriert werden
Edge-Operatoren	Protokoll zwischen Operator und Controller mit der CRD umbenannt	im selben Wartungsfenster wie den Controller aktualisieren
REST / octo-cli / MCP	`/v1/pool` → `/v1/deploymentsite`, `Pool`-Befehle → `DeploymentSite`	Skripte und Integrationen anpassen; die zum Cluster passende octo-cli-Version verwenden
Blueprints	Bereiche `System.Communication-[x,4.0)` sind nicht mehr erfüllbar	jeden betroffenen Blueprint auf seine neue Major heben (siehe Blueprints und CK-Modelle)
Blueprint-Installation	Abhängigkeiten lösen auf die höchste passende Version über alle Kataloge auf; eine Installation stuft keine Abhängigkeit mehr herab	Skripte prüfen, die sich auf das alte Verhalten verlassen haben
Adapter	SDK für 4.x gebaut; `OCTO_ADAPTER__TENANTID` veraltet; TLS-Prüfung auch auf der Hub-Verbindung	jeden extern gebauten Adapter neu releasen, Zertifikate prüfen
Pipelines	Cron-Ausführungen melden den Trigger-Typ `Scheduled`	Dashboards anpassen, die Cron-Läufe als `Event` zählen
Metriken / Alerting	`octo.workload.kind="pool"` → `"deployment_site"` / `"adapter_pool"`	Dashboards und Alert-Regeln im selben Fenster umstellen
Refinery Studio	Pools werden zu Deployment Sites, keine Weiterleitung für `communication/pools`	Studio zuletzt ausrollen
Adapter Pools und Leasing	neu, standardmäßig aus	nichts; während des Upgrades nicht einschalten

Vor dem Upgrade

Planen Sie ein Wartungsfenster, das die Core-Services, die Operatoren (zentral und edge), die Adapter und die Blueprint-Updates der Installation abdeckt. Adapter laufen während des Fensters weiter, aber zwischen dem Controller- und dem Operator-Rollout sind keine Deployments und keine Workload-Änderungen möglich.
Stoppen Sie automatische Deployments. Pausieren Sie jede Pipeline, die Core-Services, Operatoren, Adapter-Charts oder Apps automatisch in den Ziel-Cluster ausrollt — auch Pipelines, die durch Builds des Main-Branches ausgelöst werden, und Pipelines, die Adapter oder Apps auf einer eigenen Release-Linie veröffentlichen. Ein Teil-Rollout, bei dem einige Services schon r3.5.0 und andere noch r3.4.x fahren, hinterlässt Tenants mit nicht auflösbaren CK-Modellen. Lassen Sie sie pausiert, bis die Beobachtungsphase nach dem Upgrade abgeschlossen ist.
Erstellen Sie ein Backup im Cluster von der Systemdatenbank (octosystem), von jeder Tenant-Datenbank und von den Job-Datenbanken (Hangfire). Führen Sie es als Job im Cluster aus (zum Beispiel mit mongodump --archive --gzip in einem Backup-Pod) und kopieren Sie es danach aus dem Cluster heraus. Ein Dump, der über kubectl exec oder einen Port-Forward auf eine Arbeitsstation gestreamt wird, überträgt Collections mit mehreren Gigabyte nicht zuverlässig. Prüfen Sie, dass das Backup die großen Collections enthält, vor allem die GridFS-Collections fs.files und fs.chunks von octosystem und die Event-Collections der Tenants. Sichern Sie auch die Custom Resources und die Helm-Werte:
```
kubectl get communicationpools.octo-mesh.meshmakers.io -A -o yaml > communicationpools-backup.yaml
helm get values <release> -n <namespace> -o yaml > <release>-values.yaml
```
Den Stream-Data-Speicher (CrateDB) fasst die Migration nicht an; ein Backup ist optional.
Halten Sie den aktuellen Stand fest, damit Sie ihn nach der Migration vergleichen können:
```
octo-cli -c LibraryStatus
octo-cli -c ListBlueprintInstallations
```
Notieren Sie die installierte System.Communication-Version und zählen Sie die Entitäten, die migriert werden (siehe Migration prüfen). Halten Sie auch die HelmRepository-Assoziationen jedes Adapters fest (siehe Assoziationen zu Helm-Repositories).
Prüfen Sie die System.Communication-Version der Tenants. r3.5.0 migriert Tenants auf 3.35.0 bis 3.41.0. Ein Tenant auf 3.42.0 wird abgelehnt (siehe Datenmigration).
Prüfen Sie die Blueprints. Jeder installierte Blueprint, der von System.Communication mit einer Obergrenze unter 4.0 abhängt (zum Beispiel System.Communication-[3.22,4.0)), braucht seine neue Major-Version. Stellen Sie sicher, dass diese Versionen vor dem Upgrade im Katalog veröffentlicht sind (siehe Blueprints und CK-Modelle).
Suchen Sie alle alten Helm-Schlüssel. Helm ignoriert unbekannte Werte still. Ein Operator, der weiterhin autoManagePools bekommt, fällt in den Edge-Modus und deployt nichts. Durchsuchen Sie jede Values-Datei und jedes Overlay:
```
grep -rnE 'autoManagePools|poolNamespace|defaultPoolName|communicationpools|CommunicationPool' <your-deployment-repo>
```
Prüfen Sie die Zertifikate der Edge-Sites. Ab r3.5.0 prüfen Adapter auf jeder Verbindung die TLS-Zertifikate der Plattform-Services, auch auf der Hub-Verbindung (siehe Prüfung der TLS-Zertifikate). Ein Adapter an einem Edge-Site, der sich über ein privates oder selbstsigniertes Zertifikat oder über einen Proxy mit TLS-Inspection verbindet, braucht die ausstellende CA in seinem Trust Store.
Prüfen Sie die Edge-Geräte. CRDs gelten clusterweit. Betreibt ein Edge-Gerät Operatoren für mehr als eine Installation, betrifft sein CRD- und Operator-Upgrade alle davon; planen Sie dieses Gerät in das Fenster der Installation ein, die zuletzt aktualisiert wird, oder ziehen Sie den Site der anderen Installation vorher um.
Halten Sie octo-cli in beiden Versionen bereit. Verwenden Sie gegen Cluster, die noch r3.4.x fahren, die octo-cli aus r3.4.x und gegen aktualisierte Cluster die octo-cli aus r3.5.0 (siehe API, octo-cli und MCP).

Reihenfolge des Upgrades

Führen Sie die Schritte in dieser Reihenfolge aus und warten Sie jeweils, bis jeder Workload bereit ist.

CRDs: Installieren Sie das CRD-Chart von r3.5.0. Es fügt deploymentsites.octo-mesh.meshmakers.io hinzu. Die alte CRD communicationpools trägt helm.sh/resource-policy: keep und bleibt stehen; lassen Sie sie vorerst so.
Alter Operator: Skalieren Sie den Communication Operator aus r3.4.x auf null Repliken, damit er nicht auf die alten Custom Resources reagiert, während der Controller migriert.
Core-Services in einem Zug: Rollen Sie alle Core-Services auf r3.5.0 aus — zuerst Identity (importiert das System-Modell), dann Asset Repository, Platform, Bot und zuletzt den Communication Controller. Der Communication Controller importiert System.Communication 4.x und migriert jeden Tenant. Kein Core-Service darf auf einem r3.4.x-Image bleiben.

Bot vor dem Controller
Der Bot-Service muss bereit sein (Pod bereit und sein Hangfire-Server registriert), bevor der Communication Controller startet. Sonst migriert der Controller zwar die Daten, startet aber die meisten Tenants nicht (Failed to start deferred tenant), und sie erholen sich nicht von selbst. Ein Helm-Upgrade des Core-Charts rollt alle Services gleichzeitig; prüfen Sie deshalb nach dem Rollout das Controller-Log. Erscheint die Meldung oder wurde der Bot während des Controller-Starts neu gestartet, starten Sie den Communication Controller neu, sobald der Bot bereit ist.
AI, Reporting und weitere Services: Rollen Sie die Charts der übrigen Plattform-Services (AI, Reporting, Office, MCP) auf r3.5.0 aus.
Operatoren direkt nach dem Controller: Rollen Sie den Communication Operator aus r3.5.0 mit den umbenannten Helm-Werten aus (siehe Operator und Helm-Werte), zentral und auf jedem Edge-Cluster. Ein Operator aus r3.4.x kann nicht mit einem Controller aus r3.5.0 sprechen.
Deployment Sites pro Tenant neu deployen. Die Custom Resources werden nicht konvertiert, und der Operator legt sie nach dem Upgrade nicht von selbst neu an: Der Controller hält die Liste der deployten Sites im Speicher, nach seinem Neustart registriert sich ein frisch gestarteter Operator deshalb mit null Sites, auch mit autoManageDeploymentSites: true. Deployen Sie jeden Site jedes Tenants neu:
```
octo-cli -c GetDeploymentSites
octo-cli -c DeployDeploymentSite -id <deploymentSiteRtId>
```
Das legt die DeploymentSite-Resources an; laufende Adapter-Pods werden nicht neu gestartet.
Adapter: Rollen Sie das Mesh-Adapter-Chart aus r3.5.0 und die Releases der r3.5-Linie aller extern gebauten Adapter aus (siehe Adapter).
Pro Tenant: Kataloge aktualisieren, CK-Modelle prüfen und Caches leeren. Arbeiten Sie die Tenants nacheinander ab, nicht parallel:
```
octo-cli -c RefreshCatalogs
octo-cli -c RefreshBlueprintCatalogs
octo-cli -c LibraryStatus
octo-cli -c FixAll -w -y
octo-cli -c ClearCache
```
Danach die Migration prüfen und die Blueprints auf ihre neuen Majors heben.
Refinery Studio zuletzt, wenn alle Back-End-Services r3.5.0 fahren.
Alte Custom Resources und alte CRD entfernen, sobald jeder Site wieder deployt ist. Die alten Resources tragen einen Finalizer des Operators aus r3.4.x, der nicht mehr läuft; entfernen Sie ihn vor dem Löschen. Das Löschen der CRD löscht jede verbliebene CommunicationPool-Resource in allen Namespaces; stellen Sie sicher, dass keine andere Installation im selben Cluster sie noch verwendet:
```
kubectl get communicationpools.octo-mesh.meshmakers.io -A
kubectl patch communicationpools.octo-mesh.meshmakers.io <name> -n <namespace> \
  --type merge -p '{"metadata":{"finalizers":[]}}'
kubectl delete communicationpools.octo-mesh.meshmakers.io <name> -n <namespace>
kubectl delete crd communicationpools.octo-mesh.meshmakers.io
```
Observability: Stellen Sie Dashboards und Alert-Regeln im selben Fenster von octo.workload.kind="pool" auf deployment_site (und adapter_pool) um. Neue Serien können in den ersten Auswertungen <no value> zeigen.
Automatische Deployments wieder aufnehmen erst nach einer Beobachtungsphase (wir empfehlen 24 Stunden) ohne neue Fehlerklassen.

Datenmigration

Die Migration ist Teil des Modells System.Communication 4.x und läuft automatisch, wenn der Communication Controller es in einen Tenant importiert.

Einstiegspunkte: Jede veröffentlichte 3.x-Version von 3.35.0 bis 3.41.0 (3.35.0, 3.36.0, 3.37.x, 3.38.0, 3.39.x, 3.40.0, 3.41.0) migriert mit demselben Skript auf 4.6.0; die 4.x-Versionen nach 4.0.0 sind additiv.
Kein Einstiegspunkt: 3.42.0. System.Communication 3.42.0 speichert einige Attribute als verschlüsselte SECRET-Werte. r3.5.0 hat dafür bewusst keinen Migrationseintrag, weil er verschlüsselte Werte auf Klartext-Attribute umbenennen würde. Ein Tenant auf 3.42.0 wird abgelehnt (siehe Sicherheitsnetz unten) und bleibt auf 3.x; ihn migriert ein späteres r3.5.x-Release, dessen Modell den Einstiegspunkt 3.42.0 enthält.
Was konvertiert wird: Der CK-Typ jeder Pool-Entität wird zu DeploymentSite (rtId, Well-Known-Name und Attributwerte bleiben erhalten); jede Manages-Kante wird zu einer Hosts-Kante; Adapter behalten ihren Deployment Site.
Was nicht konvertiert wird: die Kubernetes Custom Resources (siehe oben) sowie Runtime-Modelle und Seed-Dateien, die Sie selbst pflegen. Dateien, die noch System.Communication/Pool oder die Rolle Manages verwenden, lassen sich auf 4.x nicht mehr importieren und müssen angepasst werden.
Sicherheitsnetz: Ein Upgrade, das ohne Migrationseintrag eine Major-Version überspringen würde, wird abgelehnt. Der CK-Import meldet dann:
```
A schema-only bridge across a major version is refused because it would skip the data migration.
```
Der Tenant bleibt auf seinen 3.x-Daten. Umgehen Sie die Sperre nicht, sondern wenden Sie sich an den Support.

Migration prüfen

Vergleichen Sie für jeden Tenant vorher und nachher:

Prüfung	Erwartung nach dem Upgrade
`LibraryStatus`	`System.Communication` 4.6.0, alle Modelle aufgelöst, kein `ResolveFailed`, nichts mit Handlungsbedarf
Entitäten vom Typ `System.Communication/Pool`	0
Entitäten vom Typ `System.Communication/DeploymentSite`	Anzahl der `Pool`-Entitäten vorher
Kanten mit der Rolle `Manages`	0
Kanten mit der Rolle `Hosts`	Anzahl der `Manages`-Kanten vorher
Adapter	dieselbe Anzahl wie vorher, jeder mit seinem Deployment Site
Deployment Sites in `GetDeploymentSites`	alle Sites, `Online`, nachdem sich der Operator wieder verbunden hat
`DeploymentSite`-Resources in Kubernetes	eine pro Site, Status `Registered`
Controller-Log	kein `Failed to start deferred tenant`, kein `System tenant database does not exist`

Assoziationen zu Helm-Repositories

Der Communication Controller aus r3.5.0 wendet beim Start den Seed des Blueprints System.Communication erneut an. Ein Adapter, der mit zwei HelmRepository-Entitäten verbunden war, behält nur eine davon; die zweite Assoziation (typischerweise die zu einem Release-Chart-Repository) wird entfernt. Vergleichen Sie die vor dem Upgrade festgehaltenen Assoziationen und stellen Sie fehlende wieder her, wo der Adapter sie braucht, bevor Sie neue Adapter-Charts ausrollen.

Blueprints und CK-Modelle

r3.5.0 erscheint zusammen mit neuen Major-Versionen aller Blueprints und CK-Modelle, die von System.Communication abhängen. Die 1.x-Linien (und die übrigen Linien vor 4.x) bleiben parallel in den Katalogen, damit Installationen, die noch r3.4.x fahren, sie weiter nutzen können; installieren Sie sie nicht auf einer r3.5.0-Installation.

Modell oder Blueprint	Version für r3.5.0
`System.Communication` (CK, vom Controller importiert)	4.6.0
`System.Ai` (CK, vom AI-Service importiert)	4.3.0 — Zugangsdaten sind SECRET-Attribute
`Loxone` (CK)	5.1.0 — das Miniserver-Passwort ist ein SECRET-Attribut. 5.0.0 ist dasselbe Modell mit Klartext-Passwort; Tenants auf 5.0.0 können auf 5.1.0 aktualisieren
`MeshmakersAccounting` / `.Tesla` / `.Host`	2.2.0 / 2.1.0 / 2.0.0
`EnergyCommunity.Base` / `.Billing` / `.Simulation`	2.11.1 / 2.8.1 / 2.8.2
`EnergyCommunity.App` / `.EdaIntegration`	2.1.0 / 2.11.0
`OneTimeTicket.Release` / `.MainLatest`	2.0.0
`FdaSeen.Base`	2.0.0
`ZenonDynprop.MainLatest`	2.0.0
`Samples.PipelineBasics` / `.Photovoltaics` / `.Simulator.EnergyCommunity`	2.0.0 / 2.0.1 / 2.0.0
`Office.ExcelImport`	2.0.0
`SmartMeterInsights.Base`	2.0.0
`FamilyOs.Release` / `.MainLatest`	2.0.0

Heben Sie jeden installierten Blueprint auf die höchste Version seiner neuen Major, im Merge-Modus. Bei Energiegemeinschaften in der Reihenfolge Base → Billing / EdaIntegration → Simulation → App. Sehen Sie sich das Update vorher an:

octo-cli -c RefreshBlueprintCatalogs
octo-cli -c PreviewBlueprintUpdate -tv MeshmakersAccounting-2.2.0
octo-cli -c UpdateBlueprint -tv MeshmakersAccounting-2.2.0 -m Merge

CK-Modelle, die zu keinem Blueprint gehören, etwa Loxone, importieren Sie aus dem Katalog und prüfen das Ergebnis danach mit LibraryStatus (-w kann Erfolg melden, bevor das Modell aufgelöst ist):

octo-cli -c ImportFromCatalog -cn <catalogName> -m Loxone-5.1.0 -w
octo-cli -c LibraryStatus

Geänderte Auflösung von Abhängigkeiten

Höchste passende Version über alle Kataloge. Ein Abhängigkeitsbereich eines Blueprints löst jetzt auf die höchste Version auf, die ihn in irgendeinem lesbaren Katalog erfüllt. Bisher gewann der erste Katalog mit irgendeiner passenden Version, sodass ein öffentlicher Katalog eine neuere Version aus einem privaten Katalog verdecken konnte.
Kein Downgrade. Ein Abhängigkeitsbereich ist ein Minimum, kein Ziel. Fährt ein Tenant bereits eine neuere Version einer Abhängigkeit, die alle deklarierten Bereiche erfüllt, behält die Installation eines Blueprints sie bei — kein Seed-Import, keine Änderung am Installationseintrag. Liegt die installierte Version außerhalb eines deklarierten Bereichs, scheitert die Installation, statt herabzustufen. Bisher konnte die Installation eines Blueprints die Seed-Daten einer älteren Abhängigkeit erneut anwenden und die ältere Version als installiert eintragen.
Blueprint-Kataloge lassen sich abschalten. Die GitHub-Blueprint-Kataloge haben wie die CK-Kataloge eine Option IsEnabled. Ein abgeschalteter Katalog wird bei Auflistung, Suche, Auflösung von Abhängigkeiten, Installation und Refresh übersprungen. Standard ist true, also das bisherige Verhalten.

Rollback

Ein Teil-Rollback gibt es nicht. Nur die Images zurückzurollen funktioniert nicht, weil Code aus r3.4.x keine 4.x-Modelle lesen kann. In einer Generalprobe mit 24 Datenbanken dauerte die Wiederherstellung etwa drei bis fünf Minuten.

Alle automatischen Deployments in den Cluster pausieren.
Die Services aus r3.5.0 stoppen.
octosystem, jede Tenant-Datenbank und die Job-Datenbanken löschen (dropDatabase) und danach aus dem Backup vor dem Upgrade wiederherstellen. Verlassen Sie sich nicht allein auf mongorestore --drop: Es löscht nur die Collections, die im Archiv enthalten sind; Collections, die r3.5.0 angelegt hat (zum Beispiel RtEntity_SystemCommunicationLentAdapterPool), bleiben sonst zurück.
Images, Charts und Operatoren auf das letzte r3.4.x-Release zurückrollen.
Die alte CRD neu installieren und die Custom Resources aus communicationpools-backup.yaml wiederherstellen.
Den CK-Cache jedes Tenants leeren (octo-cli -c ClearCache) oder die Services neu starten.

Daten, die nach der Migration geschrieben wurden, gehen verloren. Entscheiden Sie über einen Rollback innerhalb des Wartungsfensters; danach wird vorwärts korrigiert.

Operator und Helm-Werte

Wert in r3.4.x	Wert in r3.5.0
`operator.autoManagePools`	`operator.autoManageDeploymentSites`
`operator.poolNamespace`	`operator.deploymentSiteNamespace`
`operator.defaultPoolName`	`operator.defaultDeploymentSiteName`

Die Custom Resource ändert sich von

apiVersion: octo-mesh.meshmakers.io/v1alpha1
kind: CommunicationPool
spec:
  tenantId: "meshtest"
  poolRtId: "65d5c447b420da3fb12381bb"

apiVersion: octo-mesh.meshmakers.io/v1
kind: DeploymentSite
spec:
  tenantId: "meshtest"
  deploymentSiteRtId: "65d5c447b420da3fb12381bb"

Die vollständige Resource finden Sie unter Deployment Sites — Installation.

Edge-Operatoren müssen im selben Fenster wie der Communication Controller aktualisiert werden. Ein nicht erreichbarer Edge-Cluster behält seine laufenden Workloads, kann aber keine Deployments empfangen, bis sein Operator r3.5.0 fährt.

Neue Werte, die bis zur Konfiguration inaktiv sind

r3.5.0 bringt Helm-Werte mit, die mit ihren Standardwerten nichts ändern. Konfigurieren Sie sie in einer eigenen Änderung nach dem Upgrade.

Wert	Standard	Wirkung, wenn konfiguriert
`services.communication.hubAuthorization.adapterMode` / `operatorMode` (Core-Chart)	`LogOnly`	`LogOnly` protokolliert Verbindungen zu Adapter- und Operator-Hub, die ein durchsetzender Controller ablehnen würde, nur und zählt sie in der Metrik `octo.communication.hub.authorization.decisions` (`outcome=would_refuse`). `Enforce` lehnt sie ab. Stellen Sie pro Cluster erst auf `Enforce` um, wenn der Zähler über einen Prüfzeitraum bei null geblieben ist; Operatoren brauchen vorher Credentials unter `operator.authentication.*`. Jeder andere Wert lässt das Rendern scheitern
`operator.authentication.*` (Operator-Chart)	leer	Client-Credentials, mit denen sich der Operator am Operator-Hub anmeldet; Voraussetzung für `operatorMode: Enforce`
`secrets.communicationInstanceSecretKey`, `secrets.secretEncryptionKeys`, `secrets.secretEncryptionActiveKeyId` (Core-Chart)	leer	Key Ring für SECRET-Attributwerte; leer heißt, es wird kein Key Ring gerendert
`operator.clusterSecrets.instanceSecretKey` und die zugehörigen Key-Ring-Werte (Operator-Chart)	leer	Key Ring, der in Workloads mit Cluster-Secrets injiziert wird; muss zum Core-Chart passen
`secrets.secretEncryptionRequired` / `operator.clusterSecrets.secretEncryptionRequired`	`false`	`true` lässt das Rendern scheitern, wenn der Key Ring leer oder kein gültiger 32-Byte-Schlüssel ist; auf zentralen Clustern einschalten, sobald der Schlüssel geprüft ist, auf Edge-Operatoren ohne Key Ring aus lassen
`operator.adapterIgnoreCertificateValidation` (Operator-Chart)	`false`	schaltet die TLS-Zertifikatsprüfung in jedem Workload ab, den der Operator deployt. Nur für Entwicklungs-Cluster; besser `secrets.rootCa` verwenden (siehe Prüfung der TLS-Zertifikate)

Adapter

Extern gebaute Adapter

Adapter kompilieren die Construction-Kit-Runtime und das Communication-SDK in ihr Image. Jeder Adapter, der nicht aus dem Plattform-Release selbst gebaut wird, muss auf der r3.5-Linie neu released werden: finAPI, EDA, Loxone, SAP, weClapp (mit dem DILOS-Plug), Modbus (Plug und Socket), zenon, MQTT, die Demo-Adapter und jeder kundenspezifische Adapter. Ein für r3.4.x gebautes Adapter-Image läuft nach dem Core-Upgrade weiter, aber lassen Sie es nicht auf der alten Linie: Die nächste Modelländerung, die es einkompiliert, stoppt es, und ein Adapter, der gegen ein geändertes System-Modell neu startet, meldet System tenant database does not exist.

Rollen Sie die neu releasten Adapter nach den Core-Services des Clusters aus. Ein Adapter der r3.5-Linie darf nicht in einen Cluster deployt werden, der noch r3.4.x fährt.
Releasen Sie den finAPI-Adapter im selben Wartungsfenster wie das Core-Upgrade des jeweiligen Clusters neu, und bauen Sie ihn gegen das veröffentlichte r3.5.0-SDK, nicht gegen Pakete eines Entwicklungs-Builds.
Solange einzelne Cluster noch r3.4.x fahren, muss ein Hotfix für diese Cluster ausdrücklich gegen das r3.4.x-SDK gebaut werden.
Edge-Adapter, die beim Kunden als Windows-Dienst laufen (zenon, SAP), werden manuell installiert; prüfen Sie vor der Übergabe ihre Zertifikate (siehe unten).

Konfigurationsschlüssel `OCTO_ADAPTER__TENANTID`

Die Adapter-Option für den Tenant des Adapters wurde umbenannt: AdapterOptions.TenantId → AdapterOptions.DedicatedTenantId, Umgebungsvariable OCTO_ADAPTER__TENANTID → OCTO_ADAPTER__DEDICATEDTENANTID.

In r3.5.0 gilt der alte Schlüssel noch und schreibt beim Start eine Warnung: OCTO_ADAPTER__TENANTID is deprecated and will be removed in the next release.
Sind beide Schlüssel gesetzt, gewinnt der neue.
Der alte Schlüssel entfällt mit dem nächsten Release. Bis dahin sollten Adapter-Charts beide Schlüssel mit demselben Wert rendern; nur noch den neuen erst dann, wenn kein Image der alten Linie mehr deployt ist.
Eigener Adapter-Code, der AdapterOptions.TenantId liest, kompiliert gegen das r3.5-SDK nicht mehr und muss DedicatedTenantId verwenden.

Prüfung der TLS-Zertifikate

Das SDK prüft jetzt die Server-Zertifikate der Plattform-Services auf allen Verbindungen, auch auf der SignalR-Hub-Verbindung zwischen Adapter und Communication Controller, die in r3.4.x jedes Zertifikat akzeptierte.

Adapter, die die Plattform über ein öffentliches Zertifikat erreichen, sind nicht betroffen.
Adapter, die sie über eine private CA, ein selbstsigniertes Zertifikat oder einen Proxy mit TLS-Inspection erreichen, brauchen diese CA in ihrem Trust Store. Die Adapter-Charts installieren sie aus dem Chart-Wert secrets.rootCa mit einem Init-Container; Adapter, die als Windows-Dienst laufen, brauchen die CA im Windows-Zertifikatsspeicher.
IgnoreCertificateValidation=true schaltet die Prüfung für Testumgebungen ab. Die Einstellung wird abgelehnt, wenn ASPNETCORE_ENVIRONMENT oder DOTNET_ENVIRONMENT auf Production steht, und schreibt überall sonst eine Warnung. Der Operator-Wert operator.adapterIgnoreCertificateValidation setzt sie für jeden Workload eines Clusters; lassen Sie ihn außerhalb von Entwicklungs-Clustern auf false.

Prüfung der Datastore-Hosts

Ein Adapter mit einem konfigurierten Datastore-Hostnamen, der nicht auflösbar ist, bricht jetzt den Start mit einer Fehlermeldung ab, die die Einstellung nennt, statt bei der ersten Ausführung zu scheitern.

API, octo-cli und MCP

r3.4.x	r3.5.0
`GET {tenantId}/v1/pool`	`GET {tenantId}/v1/deploymentsite`
`POST {tenantId}/v1/pool/deploy?poolRtId=…`	`POST {tenantId}/v1/deploymentsite/deploy?deploymentSiteRtId=…`
`POST {tenantId}/v1/pool/undeploy?poolRtId=…`	`POST {tenantId}/v1/deploymentsite/undeploy?deploymentSiteRtId=…`
`POST {tenantId}/v1/pool/workloads/deploy` / `undeploy`	`POST {tenantId}/v1/deploymentsite/workloads/deploy` / `undeploy`
`octo-cli -c GetPools`	`octo-cli -c GetDeploymentSites`
`octo-cli -c DeployPool -id <poolRtId>`	`octo-cli -c DeployDeploymentSite -id <deploymentSiteRtId>`
`octo-cli -c UndeployPool -id <poolRtId>`	`octo-cli -c UndeployDeploymentSite -id <deploymentSiteRtId>`
MCP `get_pools`	MCP `get_deployment_sites`
MCP `undeploy_pool`	MCP `undeploy_deployment_site`

Verwenden Sie gegen eine r3.5.0-Installation die r3.5.0-Version von octo-cli und des MCP-Servers und gegen eine noch nicht aktualisierte Installation die r3.4.x-Version. Das betrifft vor allem Deployment-Automatisierung, die die jeweils neueste octo-cli herunterlädt: Gegen einen r3.4.x-Cluster gelingt UpdateWorkloadChartVersion aus r3.5.0 noch, das folgende DeployWorkload scheitert aber mit HTTP 404 — der Workload hat dann die neue Chart-Version, ist aber nicht deployt. Pinnen Sie die octo-cli-Version pro Cluster, bis alle Cluster r3.5.0 fahren.

GraphQL-Abfragen auf SystemCommunicationPool müssen stattdessen den Deployment-Site-Typ verwenden.

Behoben: Updates von To-One-Assoziationen über Runtime-Queries

Das Aktualisieren von Zeilen einer Runtime-Query über GraphQL (runtimeQuery.update) konnte Assoziationsänderungen in umgekehrter Richtung schreiben und To-Many-Navigationen ersetzen, wenn die Gegenseite der Rolle die Multiplizität ZeroOrOne hat. r3.5.0 bestimmt die Richtung nur noch über die navigierte Seite. Haben Sie das alte Verhalten umgangen, entfernen Sie den Workaround.

Observability

Die Workload-State-Metriken kennzeichnen Sites mit octo.workload.kind="deployment_site" und Adapter Pools mit octo.workload.kind="adapter_pool". Für "pool" gibt es keinen Alias: Regeln und Dashboards, die darauf filtern, treffen nichts mehr.
Pipeline-Ausführungen, die ein Cron-Zeitplan startet, melden den Trigger-Typ Scheduled, auf dedizierten Adaptern ebenso wie auf Adapter Pools; Event bleibt echten Bus-Ereignissen vorbehalten. Dashboards und Filter der Ausführungshistorie, die Cron-Läufe unter Event zählen, müssen angepasst werden.
Der Communication Controller zählt Entscheidungen der Hub-Autorisierung in octo.communication.hub.authorization.decisions. Im Modus LogOnly zeigt die Serie mit outcome=would_refuse, welche Verbindungen ein durchsetzender Controller ablehnen würde.
Leasing bringt Metriken unter octo.lease.* und octo.pool.*. Alert-Regeln für Leasing sind nur auf Installationen sinnvoll, die es einschalten.

Adapter Pools und Leasing

Nach dem Upgrade ist Leasing auf jedem Tenant aus (leasingEnabled: false), und es gibt keine Adapter Pools, bis Sie einen anlegen. Schalten Sie Leasing nicht im Rahmen des Upgrades ein, sondern in einer eigenen Änderung, zuerst für einen verleihenden und einen leihenden Tenant:

octo-cli -c GetCommunicationLifecycle
octo-cli -c SetCommunicationLifecycle -le true

Ein Lease braucht eingeschaltetes Leasing auf beiden Seiten, beim verleihenden und beim leihenden Tenant. Erneutes Ausschalten hält die Queue an.

Bekannte Einschränkungen

Betreiben Sie den Communication Controller mit einer Replika. Der Lease-Zustand lebt im Controller-Prozess; persistente Leases für mehrere Repliken sind geplant (AB#5878).
Leasing ist auf jedem Tenant standardmäßig aus.
Refinery Studio hat noch keine Seiten für Adapter Pools und Leasing; sie folgen mit einem späteren Studio-Release. Bis dahin verwenden Sie octo-cli, die MCP-Tools oder die REST-API.
Adapter Pools lehnen ReceivesClusterSecrets und Ingress-Konfiguration ab; ExecuteCSharp@1 auf einem Pool braucht ein Memory-Limit von mindestens 1 Gi.
Geleaste Ausführungen können keine SECRET-Attributwerte offenlegen und haben keinen Zugriff auf Stream Data (CrateDB).
Änderungen an einem Pool erreichen leihende Tenants erst nach POST {tenantId}/v1/adapterpool/mirrors/publish.
Tenants auf System.Communication 3.42.0 migriert r3.5.0 nicht (siehe Datenmigration).

Schon r3.4.149 hat die Tenant-REST-API von Identity geändert: Sie verlangt die Rolle UserManagement oder TenantManagement (standardmäßig erzwungen) und bietet GET users/directory für Benutzerauswahlen. Wenn Sie von einem Release vor r3.4.149 kommen, prüfen Sie, dass die Benutzer und Clients, die Tenants verwalten, eine dieser Rollen haben.

Was sich ändert​

Vor dem Upgrade​

Reihenfolge des Upgrades​

Datenmigration​

Migration prüfen​

Assoziationen zu Helm-Repositories​

Blueprints und CK-Modelle​

Geänderte Auflösung von Abhängigkeiten​

Rollback​

Operator und Helm-Werte​

Neue Werte, die bis zur Konfiguration inaktiv sind​

Adapter​

Extern gebaute Adapter​

Konfigurationsschlüssel OCTO_ADAPTER__TENANTID​

Prüfung der TLS-Zertifikate​

Prüfung der Datastore-Hosts​

API, octo-cli und MCP​

Behoben: Updates von To-One-Assoziationen über Runtime-Queries​

Observability​

Adapter Pools und Leasing​

Bekannte Einschränkungen​

Verwandt: Rollen für die Tenant-API von Identity​