#dusk $DUSK @Dusk
Ein Node-Upgrade kann technisch erfolgreich sein und dennoch operativ scheitern.
Das ist genau das, was ich am Upgrade-Prozess von Dusk wichtig finde.
Das Installationsprogramm ist so ausgelegt, dass die Teile geschützt werden, die ein Upgrade überleben sollen, einschließlich Konsensschlüsseln und Chain-State. Gleichzeitig werden einige Konfigurationsdateien und die systemd-Servicedefinition neu erstellt. Das bedeutet: Der Betreiber muss die Einstellungen, die festlegen, was die Maschine tun soll, explizit wiederherstellen.
Für einen normalen Validator ist das Fehlen eines Feature-Flags möglicherweise nur unbequem. Für einen Archive-Betreiber kann es jedoch viel ernster sein: Der Node kann online bleiben, Blöcke produzieren oder ihnen folgen und dabei gesund wirken, während er still und leise die Archiv-Rolle verliert, von der die Anwendungen abhängen.
Ich mag außerdem, dass Dusk das ersetzte Binary überprüft, bevor Rusk angehalten wird, und den Dienst danach auch weiterhin gestoppt lässt. Das gibt dem Betreiber die Möglichkeit, die neue Konfiguration zu prüfen, anstatt blind alles neu zu starten.
Aber das bedeutet auch eine wichtige Verantwortung für den Menschen.
Das sicherste Upgrade ist nicht notwendigerweise das mit dem wenigsten manuellen Aufwand. Es ist das, bei dem der Betreiber bestätigen kann, dass der Node mit der richtigen Rolle, den richtigen Features und den richtigen Netzwerkeinstellungen wieder gestartet ist.
Für mich ist das die eigentliche Upgrade-Prüfung bei Dusk:
Läuft der Node — oder läuft er nur den Job, für den er tatsächlich bereitgestellt wurde?
#DUSK @DuskFoundation $GPS $ACE
Ein Node-Upgrade kann technisch erfolgreich sein und dennoch operativ scheitern.
Das ist genau das, was ich am Upgrade-Prozess von Dusk wichtig finde.
Das Installationsprogramm ist so ausgelegt, dass die Teile geschützt werden, die ein Upgrade überleben sollen, einschließlich Konsensschlüsseln und Chain-State. Gleichzeitig werden einige Konfigurationsdateien und die systemd-Servicedefinition neu erstellt. Das bedeutet: Der Betreiber muss die Einstellungen, die festlegen, was die Maschine tun soll, explizit wiederherstellen.
Für einen normalen Validator ist das Fehlen eines Feature-Flags möglicherweise nur unbequem. Für einen Archive-Betreiber kann es jedoch viel ernster sein: Der Node kann online bleiben, Blöcke produzieren oder ihnen folgen und dabei gesund wirken, während er still und leise die Archiv-Rolle verliert, von der die Anwendungen abhängen.
Ich mag außerdem, dass Dusk das ersetzte Binary überprüft, bevor Rusk angehalten wird, und den Dienst danach auch weiterhin gestoppt lässt. Das gibt dem Betreiber die Möglichkeit, die neue Konfiguration zu prüfen, anstatt blind alles neu zu starten.
Aber das bedeutet auch eine wichtige Verantwortung für den Menschen.
Das sicherste Upgrade ist nicht notwendigerweise das mit dem wenigsten manuellen Aufwand. Es ist das, bei dem der Betreiber bestätigen kann, dass der Node mit der richtigen Rolle, den richtigen Features und den richtigen Netzwerkeinstellungen wieder gestartet ist.
Für mich ist das die eigentliche Upgrade-Prüfung bei Dusk:
Läuft der Node — oder läuft er nur den Job, für den er tatsächlich bereitgestellt wurde?
#DUSK @DuskFoundation $GPS $ACE