#dusk $DUSK @Dusk
Une mise à niveau peut réussir sur le plan technique tout en échouant sur le plan opérationnel.

C’est ce qui m’importe dans le processus de mise à niveau de Dusk.

L’installateur est conçu pour protéger les éléments qui doivent survivre à une mise à niveau, y compris les clés de consensus et l’état de la chaîne. Dans le même temps, certains fichiers de configuration et la définition du service systemd sont recréés. Cela signifie que l’opérateur doit explicitement restaurer les paramètres qui définissent ce que la machine est censée faire.

Pour un validateur normal, l’absence d’un indicateur de fonctionnalité peut être incommode. Pour un opérateur d’archive, cela peut être beaucoup plus grave : le nœud peut rester en ligne, produire ou suivre des blocs, et sembler en bonne santé tout en perdant silencieusement le rôle d’archive dont les applications dépendent.

J’apprécie aussi le fait que Dusk vérifie le binaire de remplacement avant d’arrêter Rusk, puis laisse le service arrêté ensuite. Cela donne à l’opérateur l’occasion d’inspecter la nouvelle configuration plutôt que de tout redémarrer aveuglément.

Mais cela impose une responsabilité importante à l’humain.

La mise à niveau la plus sûre n’est pas nécessairement celle qui demande le moins de travail manuel. C’est celle où l’opérateur peut confirmer que le nœud est revenu avec le bon rôle, les bonnes fonctionnalités et les paramètres réseau.

Pour moi, c’est le véritable contrôle de mise à niveau de Dusk :

Le nœud fonctionne — ou exécute-t-il réellement le travail pour lequel il a été déployé ?

#DUSK @DuskFoundation $GPS $ACE