Erste Schritte mit den Methoden für sichere Upgrades

2025-06-23

In diesem Artikel werden die Methoden für sichere Upgrades (Safe Upgrade Practices, SUP) von Azure Operator Service Manager (AOSM) vorgestellt. Dieser Featuresatz ermöglicht Upgrades auf komplexe Containernetzwerkfunktionen (CNF), die auf Azure Operator Nexus gehostet werden. Diese Upgrades unterstützen in der Regel Partner In Service Software Upgrade (ISSU) Methoden und Anforderungen. Während in diesem Artikel grundlegende Konzepte vorgestellt werden, suchen Sie nach anderen Artikeln, die erweiterte SUP-Features und -Funktionen erweitern.

Einführung in sichere Upgrades

Ein von AOSM unterstützter Netzwerkdienst, bestehend aus einem zu vielen CNFs, umfasst Komponenten, die im Laufe der Zeit Software- und/oder Konfigurationsänderungen erfordern. Damit diese Komponentenebenenänderungen vorgenommen werden müssen, müssen Sie einen für viele Steuervorgänge ausführen, indem Sie jede Netzwerkfunktionsanwendung (nfApp) in einer bestimmten Reihenfolge und in einer Weise aktualisieren, die sich am wenigsten auf den Netzwerkdienst auswirkt. AOSM-Methoden für sichere Upgrades wenden die folgenden allgemeinen Funktionen für die Behandlung von Upgradeprozess- und Workflowanforderungen an:

Unterstützung für SNS-Reput-Vorgänge: Ausführen des Helm-Upgradevorgangs für alle nfApps in der Netzwerkfunktions-Entwurfsversion (Network Function Design Version, NFDV)
Nexus-Plattform: Unterstützt SNS-Reput-Vorgänge für Nexus-Plattformziele.
Vorgangstimeouts – Möglichkeit zum Festlegen von Betriebstimeouts für jeden nfApp-Vorgang.
Synchrone Vorgänge: Bietet die Möglichkeit, jeweils einen seriellen nfApp-Vorgang auszuführen.
Steuerungsupgradereihenfolge: Definieren sie unterschiedliche nfApp-Sequenzen für die Installation und das Upgrade.
Anhalten bei Fehler: Standardmäßig wird nach einem nfApp-Vorgangsfehler angehalten.
Rollback bei Fehler: Optionales Verhalten, Rollback abgeschlossener nfApps vor fehlerhafter nfApp
Testüberprüfung eines einzelnen Charts: Dient zum Ausführen eines Helm-Testvorgangs nach der Erstellung oder einem Update.
nfApp ohne Änderung überspringen: Verarbeitung von nfApps überspringen, bei denen keine Änderungen vorliegen
Images im Voraus laden: Möglichkeit, Images im Voraus in das Edgerepository herunterzuladen.

Ansatz für sichere Upgrades

Um einen vorhandenen AOSM-Standortnetzwerkdienst (SNS) zu aktualisieren, führt der Operator eine seriöse Anforderung für die bereitgestellte SNS-Ressource aus. Wenn der SNS CNFs mit mehreren nfApps enthält, wird die Anforderung auf alle nfApps verteilt, die in der Spezifikation der Netzwerkfunktionsdefinitionsversion (NFDV) angegeben sind. Standardmäßig in der Reihenfolge, in der sie angezeigt werden, oder optional in der durch updateDependsOn Parameter definierten Reihenfolge.

Für jede nfApp unterstützt die Zuverlässigkeitsanforderung verschiedene Änderungen, darunter das Erhöhen einer Helmdiagrammversion, das Hinzufügen/Entfernen von Helmwerten und/oder das Hinzufügen/Entfernen von nfApps. Timeouts können zwar pro nfApp festgelegt werden, basierend auf bekannten zulässigen Laufzeiten, nfApps können jedoch nur nacheinander in der seriellen Reihenfolge verarbeitet werden. Das Reput-Update implementiert die folgende Verarbeitungslogik:

nfApps werden entweder updateDependsOn nach der Sortierung oder in der sequenziellen Reihenfolge verarbeitet, in der sie angezeigt werden.
nfApps, für die der applicationEnabled-Parameter auf deaktiviert festgelegt ist, werden übersprungen.
nfApps mit dem Parameter skipUpgrade, der auf enabled gesetzt ist, werden übersprungen, wenn keine Änderungen erkannt werden.
nfApps, die zwischen altem und neuem NFDV gemeinsam verwendet werden, werden mit helm upgradeaktualisiert.
nfApps, die sich nur im neuen NFDV befinden, werden mit helm installinstalliert.
nfApps bereitgestellt, aber nicht vom neuen NFDV referenziert, werden mithilfe helm deletevon .

Um ergebnisse zu gewährleisten, wird nfApp-Tests mithilfe von Helmmethoden unterstützt, entweder durch Helmvor- oder Post-Hooks ausgelöste Tests oder mithilfe des eigenständigen Helmtesthakens. Bei Pre- oder Post-Hook-Fehlern wird der atomic Parameter berücksichtigt. Bei atomic/true wird das fehlerhafte Chart zurückgesetzt. Bei atomisch/false wird kein Rollback ausgeführt. Bei eigenständigem Helm-Test-Hook-Fehler wird die rollbackOnTestFailure Würdigung berücksichtigt, die ähnliche Logik wie atom. Weitere Informationen zu eigenständigen Helmtests finden Sie im folgenden Artikel: Ausführen von Tests nach der Installation oder dem Upgrade

Wenn ein nfApp-Vorgangsfehler auftritt und nachdem die fehlgeschlagene nfApp über atomic oder rollbackOnTestFailure Parameter behandelt wurde, kann der Operator das Verhalten steuern, wie alle nfApps vor der fehlgeschlagenen nfApp geändert werden. Bei unterbrechungsgesteuertem Fehler kann der Operator AOSM erzwingen, nach der Behebung der fehlgeschlagenen nfApp einen Unterbrechungsvorgang durchzuführen, wobei die Gemischte Versionsumgebung beibehalten wird. Bei rollback-on-failure kann der Operator AOSM zum Rollback aller vorherigen nfApp erzwingen und die ursprüngliche Umgebungsmomentaufnahme wiederherstellen. Weitere Informationen zum Steuern des Upgradefehlerverhaltens finden Sie im folgenden Artikel: Steuern des Fehlerverhaltens des Upgrades

Überlegungen bei In-Service-Upgrades

Azure Operator Service Manager unterstützt allgemein In-Service-Upgrades, sprich eine Upgrademethode, bei der eine Bereitstellungsversion ohne Unterbrechung des ausgeführten Diensts aktualisiert wird. Einige Überlegungen zum Besitzer von Netzwerkfunktionen sind erforderlich, um das ordnungsgemäße Verhalten von AOSM während des ISSU-Betriebs sicherzustellen.

Wenn AOSM ein Upgrade für einen sortierten Satz von mehreren nfApps durchführt, wird AOSM zuerst aktualisiert oder es erstellt alle neuen nfApps und löscht dann alle alten nfApps. Dieser Ansatz stellt sicher, dass der Dienst nicht beeinträchtigt wird, bis alle neuen nfApps bereit sind, erfordert jedoch zusätzliche Plattformkapazität für das vorübergehende Hosting sowohl der alten als auch der neuen nfApps.
Wenn AOSM eine nfApp mit mehreren Replikaten aktualisiert, berücksichtigt AOSM die Profileinstellungen der Bereitstellung für die Rolling-Option oder Neuinstallation. Wenn Sie die Rolling-Option verwenden, machen Sie die Werte maxUnavailable und maxSurge als CGS-Parameter verfügbar, die dann zur Laufzeit über den Operator CGV festgelegt werden können.

Die Möglichkeit, einen bestimmten Dienst unterbrechungsfrei zu aktualisieren, ist letztendlich ein Feature des Diensts selbst. Wenden Sie sich weiter an den Dienstherausgeber, um die In-Service-Upgradefunktionen zu verstehen und sicherzustellen, dass sie an den richtigen AOSM-Verhaltensoptionen ausgerichtet sind.

Voraussetzungen für sichere Upgrades

Berücksichtigen Sie bei der Planung eines Upgrades mithilfe von AOSM die folgenden Anforderungen vor der Upgradeausführung, um die zeitverwendete Zeit zu optimieren und den Erfolg des Upgrades sicherzustellen.

Führen Sie das Onboarding aktualisierter Artefakte mithilfe von Herausgeber- und/oder Designerworkflows durch.
- Verwenden Sie in den meisten Fällen den vorhandenen Herausgeber, um neue Versionsartefakte zu hosten.
  - Die Verwendung eines vorhandenen Herausgebers unterstützt helm upgrade beim Aktualisieren eines SNS auf eine andere Version.
  - Für die Verwendung eines neuen Herausgebers ist ein helm delete im aktuellen SNS und dann ein helm install für die neue SNS-Version erforderlich.
- Artefaktspeicher, Netzwerkdienstentwurfsgruppe (NSDG) und Netzwerkfunktionsentwurfsgruppe (NFDG) sind unveränderlich und können sich nicht ändern.
  - Das Ändern einer dieser Ressourcen erfordert die Bereitstellung eines neuen SNS.
- Zum Speichern der neuen Charts und Images ist ein neues Artefaktmanifest erforderlich.
  - Ausführliche Informationen zum Hochladen neuer Diagramme und Bilder finden Sie in der Onboarding-Dokumentation .
- Es ist eine neue NFDV- und optional Netzwerkdienstentwurfsversion (NSDV) erforderlich.
  - NFDV-Änderungen können komplex sein. Wir behandeln nur grundlegende Änderungen in diesem Artikel.
  - Eine neue NSDV ist nur erforderlich, wenn eine neue Konfigurationsgruppenschema-Version (Configuration Group Schema, CGS) eingeführt wird.
- Falls erforderlich, ein neues Konfigurationsgruppenschema (CGS).
  - Ist erforderlich, wenn ein Upgrade neue verfügbar gemachte Konfigurationsparameter einführt.

Hinweis

NSDVs und NFDVs mit unterschiedlichen Hauptversionen können in derselben NSDG und NFDG unterstützt werden.

Erstellen Sie aktualisierte Artefakte mithilfe des Operator-Workflows.
- Erstellen Sie bei Bedarf neue Konfigurationsgruppenwerte (Configuration Group Values, CGVs) basierend auf dem neuen Konfigurationsgruppenschema (CGS).
- Verwenden Sie Nutzdaten wieder, und erstellen Sie Nutzdaten, indem Sie die vorhandenen Standort- und Standortnetzwerkdienst-Objekte bestätigen.
Aktualisieren Sie Vorlagen, um sicherzustellen, dass Upgradeparameter basierend auf der Konfidenz des Upgrades und dem gewünschten Fehlerverhalten festgelegt werden.
- In Einstellungen, die für die Produktion verwendet werden, werden Fehlerdetails möglicherweise unterdrückt. In Debug- oder Testeinstellungen können diese Details dagegen angezeigt werden.

Verfahren für sichere Upgrades

Folgen Sie dem folgenden Prozess, um ein Upgrade mit AOSM auszulösen.

Neue NFDV-Ressource erstellen
- Für neue NFDV-Versionen muss sie in einem gültigen SemVer-Format vorliegen. Die neue Version kann ein Upgrade, ein größerer Wert im Vergleich zur bereitgestellten Version oder ein Downgrade sein, ein niedrigerer Wert im Vergleich zur bereitgestellten Version. Die neue Version kann sich je nach Haupt-, Neben- oder Patchwerten unterscheiden.
Aktualisieren neuer NFDV-Parameter
- Helm-Chartversionen können aktualisiert werden, und Helm-Werte können bei Bedarf aktualisiert oder parametrisiert werden. Neue nfApps können auch hinzugefügt werden, wo sie in der bereitgestellten Version nicht vorhanden waren.
Aktualisieren der NFDV mit der gewünschten nfApp-Reihenfolge
- UpdateDependsOn ist ein NFDV-Parameter, der verwendet wird, um die Reihenfolge von nfApps während aktualisierungsvorgängen anzugeben. Falls updateDependsOn nicht angegeben, wird die serielle Sortierung von CNF-Anwendungen verwendet, wie sie im NFDV angezeigt wird.
Aktualisieren der ARM-Vorlage für das gewünschte Upgradeverhalten
- Stellen Sie sicher, dass Sie die gewünschte CNF-Anwendung timeout, den atomic Parameter und den rollbackOnTestFailure Parameter festlegen. Es kann sinnvoll sein, diese Parameter im Laufe der Zeit zu ändern, wenn Sie mehr Vertrauen in das Upgrade gewonnen haben.
Ausgeben des SNS-Reput-Vorgangs
- Nach Abschluss des Onboardings wird der Reput-Vorgang übermittelt. Je nach Anzahl, Größe und Komplexität der nfApps kann der Reput-Vorgang einige Zeit in Anspruch nehmen (mehrere Stunden).
Untersuchen der Ergebnisse des Reput-Vorgangs
- Wenn der Reput-Vorgang ein erfolgreiches Ergebnis meldet, ist das Upgrade abgeschlossen, und der Benutzer sollte den Status und die Verfügbarkeit des Diensts überprüfen. Wenn für den Reput-Vorgang ein Fehler gemeldet wird, führen Sie die Schritte im Abschnitt zur Wiederherstellung nach Upgradefehlern aus, um den Vorgang fortzusetzen.

Wiederholungsverfahren für sichere Upgrades

In Fällen, in denen ein Reput-Update fehlschlägt, können Sie die folgenden Schritte ausführen, um den Vorgang zu wiederholen.

Diagnostizieren der fehlerhaften nfApp
- Beheben Sie die Ursache für nfApp-Fehler, indem Sie Protokolle und andere Debuginformationen analysieren.
Manuelles Überspringen abgeschlossener Diagramme
- Nach dem Beheben der fehlgeschlagenen nfApp, aber bevor Sie einen Upgrade-Wiederholungsversuch unternehmen, sollten Sie den applicationEnablement Parameter ändern, um das Wiederholungsverhalten zu beschleunigen. Dieser Parameter kann auf „false“ festgelegt werden, wenn eine nfApp übersprungen werden soll. Dieser Parameter kann nützlich sein, wenn für eine nfApp kein Upgrade erforderlich ist.
Ausgeben einer SNS-Reput-Wiederholung (Wiederholen bis zur erfolgreichen Ausführung)
- Standardmäßig erfolgen die Reput-Wiederholungen für nfApps in der deklarierten Updatereihenfolge, es sei denn, sie werden mit dem applicationEnablement-Flag übersprungen.

Steuern von Timeouts mit „installOptions“ und „UpgradeOptions“

Wenn ein SNS-Vorgang entweder einen helm install oder einen helm upgradestartet, wird ein 27-Minütiger Standardtimeoutwert verwendet. Obwohl dieser Wert auf der Ebene der globalen Netzwerkfunktion (NF) angepasst werden kann, empfehlen wir, diesen Wert auf der NF-Ebene der Komponente mithilfe roleOverrideValues der NF-Nutzlastvorlage anzupassen. Eine weitere Exposentierung der roleOverrideValues in CGS/CGV ermöglicht die Steuerung durch den Operator zur Laufzeit. Das folgende Beispiel veranschaulicht unterstützte installOptions- und upgradeOptions-Parameter, die auf zwei nfApp-Komponenten angewendet werden.

{
  "roleOverrideValues": [
    {
      "name": "nfApplication1",
      "deployParametersMappingRuleProfile": {
        "helmMappingRuleProfile": {
          "options": {
            "installOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1"
            },
            "upgradeOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1"
            } } } } },
    {
      "name": "nfApplication2",
      "deployParametersMappingRuleProfile": {
        "helmMappingRuleProfile": {
          "options": {
            "installOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1"
            },
            "upgradeOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1"
            } } } } }
  ]
}

NfApps mithilfe von applicationEnablement überspringen

In der NFDV-Ressource gibt es unter deployParametersMappingRuleProfile eine unterstützte Eigenschaft applicationEnablement, die vom Typ Enum ist und Werte von "Unknown", "Enabled" oder "Disabled" akzeptiert. Sie kann verwendet werden, um nfApp-Vorgänge während der Netzwerkfunktionsbereitstellung manuell auszuschließen. Im folgenden Beispiel wird eine generische Methode veranschaulicht, um applicationEnablement als eingeschlossenen Wert in der roleOverrideValues-Eigenschaft zu parametrisieren.

Änderungen der NFDV-Vorlage

Obwohl keine NFDV-Änderungen erforderlich sind, kann der Herausgeber optional den NFDV verwenden, um einen Standardwert für die applicationEnablement Eigenschaft festzulegen. Die Voreinstellung wird verwendet, es sei denn, sie wird über roleOverrideValues geändert. Verwenden Sie die NFDV-Vorlage, um einen Standardwert für applicationEnablement festzulegen. Im folgenden Beispiel wird der Zustand enabled als Standardwert für nfApps vom Typ hellotest festgelegt.

      "location":"<location>", 
      "properties": {
      "networkFunctionTemplate": {
        "networkFunctionApplications": [
            "deployParametersMappingRuleProfile": {
              "applicationEnablement": "Enabled"
            },
            "name": "hellotest"
        ],
        "nfviType": "AzureArcKubernetes"
        },
      }

Um den applicationEnablement Wert dynamischer zu verwalten, kann der Operator einen Echtzeitwert mithilfe der NF-Vorlageneigenschaft roleOverrideValues übergeben. Obwohl es möglich ist, dass der Operator die NF-Vorlage direkt bearbeiten kann, parametrisieren Sie stattdessen die roleOverrideValues, sodass Werte zur Laufzeit über eine CGV-Vorlage übergeben werden können. Die folgenden Beispiele veranschaulichen die erforderlichen Änderungen an den CGS-, NF-Vorlagen und schließlich der CGV.

Änderungen der CGS-Vorlage

Die CGS-Vorlage muss aktualisiert werden, um eine Variablendeklaration für jede Zeile unter roleOverrideValues einzuschließen, die parametrisiert werden soll. Im folgenden Beispiel werden drei Überschreibungswerte veranschaulicht.

        "roleOverrideValues0": {
          "type": "string"        
        },    
        "roleOverrideValues1": {
          "type": "string"        
        },        
        "roleOverrideValues2": {
          "type": "string"
        }

Änderungen der NF-Nutzlastvorlage

Die NF-Vorlage muss auf drei Arten aktualisiert werden. Zuerst muss der implizite Konfigurationsparameter als Typobjekt definiert werden. Zweitens, roleOverrideValues0, , roleOverrideValues1und roleOverrideValues2 muss als Variablen deklariert werden, die dem Konfigurationsparameter zugeordnet sind. Drittens, roleOverrideValues0, , roleOverrideValues1und roleOverrideValues2 muss zur Ersetzung in roleOverrideValues der richtigen Reihenfolge und nach der richtigen Syntax verwiesen werden.

  "parameters": {
    "config": {
      "type": "object",
      "defaultValue": {}
    }
  }
  "variables": {
    "roleOverrideValues0": "[string(parameters('config').roleOverrideValues1)]",
    "roleOverrideValues1": "[string(parameters('config').roleOverrideValues1)]",
    "roleOverrideValues2": "[string(parameters('config').roleOverrideValues2)]"
  },
  "resources": [
  {
<snip>
     "roleOverrideValues": [
          "[variables('roleOverrideValues0')]",
          "[variables('roleOverrideValues1')]",
          "[variables('roleOverrideValues2')]"
        ]
   }

Änderungen der CGV-Vorlage

Die CGV-Vorlage kann jetzt aktualisiert werden, um den Inhalt jeder Variable einzuschließen, die zur Laufzeit in die roleOverrideValues-Eigenschaft eingesetzt werden soll. Im folgenden Beispiel wird rollbackEnabled auf „true“ festgelegt, gefolgt von Überschreibungssätzen für nfApplications vom Typ hellotest und hellotest1.

{
    "roleOverrideValues0": "{\"nfConfiguration\":{\"rollbackEnabled\":true}}",
    "roleOverrideValues1": "{\"name\":\"hellotest\",\"deployParametersMappingRuleProfile\":{\"applicationEnablement\":\"Enabled\",\"helmMappingRuleProfile\":{\"releaseName\":\"override-release\",\"releaseNamespace\":\"override-namespace\",\"helmPackageVersion\":\"1.0.0\",\"values\":\"\",\"options\":{\"installOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"30\",\"injectArtifactStoreDetails\":\"true\"},\"upgradeOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"30\",\"injectArtifactStoreDetails\":\"true\"}}}}}",
    "roleOverrideValues2": "{\"name\":\"hellotest1\",\"deployParametersMappingRuleProfile\":{\"applicationEnablement\" : \"Enabled\"}}"
}

Mit diesem Framework kann der Betreiber jeden der roleOverrideValues-Werte über einfache Aktualisierungen des CGV verwalten, gefolgt vom Anfügen des CGV an den gewünschten SNS-Vorgang.

NfApps ohne Änderungen überspringen

Das skipUpgrade-Feature wurde entwickelt, um die für CNF-Upgrades benötigte Zeit zu optimieren. Wenn der Herausgeber dieses Flag im roleOverrideValues unter upgradeOptions aktiviert, führt die AOSM-Dienstebene bestimmte Vorabüberprüfungen durch, um zu bestimmen, ob ein Upgrade für eine bestimmte nfApplication übersprungen werden kann. Wenn alle Vorüberprüfungskriterien erfüllt sind, wird das Upgrade für diese Anwendung übersprungen. Andernfalls wird ein Upgrade auf Clusterebene ausgeführt.

Vorüberprüfungskriterien

Ein Upgrade kann übersprungen werden, wenn alle folgenden Bedingungen erfüllt sind:

Der nfApplication-Bereitstellungsstatus ist „erfolgreich“.
Der Name oder die Version des Helmdiagramms ändert sich nicht.
Es gibt keine Änderung der Helmwerte.

Aktivieren oder Deaktivieren des skipUpgrade-Features

Das skipUpgrade-Feature ist standardmäßig deaktiviert. Wenn dieser optionale Parameter nicht unter roleOverrideValuesupgradeOptions angegeben ist, fahren CNF-Upgrades auf herkömmliche Weise fort, bei denen das nfApplications Upgrade auf Clusterebene erfolgt.

Aktivieren von SkipUpgrade innerhalb einer Netzwerkfunktionsressource

Informationen zum Aktivieren des SkipUpgrade-Features über roleOverrideValues finden Sie im folgenden Beispiel.

{
    "location": "eastus2euap",
    "properties": {
        "publisherName": "xyAzureArcRunnerPublisher",
        "publisherScope": "Private",
        "networkFunctionDefinitionGroupName": "AzureArcRunnerNFDGroup",
        "networkFunctionDefinitionVersion": "1.0.0",
        "networkFunctionDefinitionOfferingLocation": "eastus2euap",
        "nfviType": "AzureArcKubernetes",
        "nfviId": "/subscriptions/4a0479c0-b795-4d0f-96fd-c7edd2a2928f/resourcegroups/ashutosh_test_rg/providers/microsoft.extendedlocation/customlocations/ashutosh_test_cl",
        "deploymentValues": "",
        "roleOverrideValues": [
            "{\"name\":\"hellotest\",\"deployParametersMappingRuleProfile\":{\"helmMappingRuleProfile\":{\"options\":{\"installOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"1\"},\"upgradeOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"4\",\"skipUpgrade\":\"true\"}}}}}",
            "{\"name\":\"runnerTest\",\"deployParametersMappingRuleProfile\":{\"helmMappingRuleProfile\":{\"options\":{\"installOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"5\"},\"upgradeOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"5\"}}}}}"
        ]
    }
}

Erläuterung des Beispiels

nfApplication: hellotest
- Das skipUpgrade-Flag ist aktiviert. Wenn die Upgradeanforderung für hellotest die Vorüberprüfungskriterien erfüllt, wird das Upgrade übersprungen.
nfApplication: runnerTest
- Das skipUpgrade Kennzeichen ist nicht angegeben. Daher führt runnerTest ein herkömmliches Helm-Upgrade auf Clusterebene aus, auch wenn die Vorabüberprüfungskriterien erfüllt sind.

Vollständige Referenz zur roleOverrideValues-Option

In der folgenden Referenz werden alle Beispiele in diesem und anderen Artikeln zusammengefasst, und in der folgenden Referenz werden alle derzeit unterstützten Optionen veranschaulicht, die über den roleOverrideValues Mechanismus verfügbar sind.

{
  "roleOverrideValues": [
    {
      "nfConfiguration": {
        "rollbackEnabled": "true"
      }
    },
    {
      "name": "nfApplication1",
      "deployParametersMappingRuleProfile": {
        "helmMappingRuleProfile": {
          "options": {
            "installOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1",
              "testOptions": {
                "enable": "true",
                "timeout": "true",
                "rollbackOnTestFailure": "true",
                "filter": [
                  "test1",
                  "test2"
                ]
              }
            },
            "upgradeOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1",
              "skipUpgrade": "true",
              "testOptions": {
                "enable": "true",
                "timeout": "true",
                "rollbackOnTestFailure": "true",
                "filter": [
                  "test1",
                  "test2"
                ]
              }
            }
          }
        }
      }
    },
    {
      "name": "nfApplication2",
      "deployParametersMappingRuleProfile": {
        "helmMappingRuleProfile": {
          "options": {
            "installOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1",
              "testOptions": {
                "enable": "true",
                "timeout": "true",
                "rollbackOnTestFailure": "true",
                "filter": [
                  "test1",
                  "test2"
                ]
              }
            },
            "upgradeOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1",
              "skipUpgrade": "true",
              "testOptions": {
                "enable": "true",
                "timeout": "true",
                "rollbackOnTestFailure": "true",
                "filter": [
                  "test1",
                  "test2"
                ]
              }
            }
          }
        }
      }
    }
  ]
}