#dusk $PORTAL está pegando fogo hoje. originalmente pensei que fazer upgrade de um nó no @Dusk significava substituir o binário e reiniciar a mesma máquina com a mesma função.

um aviso no guia do operador me fez repensar.

@Dusk_Foundation s o instalador preserva as chaves de consenso, o estado da cadeia e a configuração de serviço selecionada. Mas ele deliberadamente regenera arquivos como rusk.toml, genesis.toml e a unidade systemd do Rusk.

Mais importante: o operador precisa repetir as flags de rede e de recursos que o nó já tinha. espere, deixa eu reservar meu lucro em $CYS

Se um operador de arquivo (archive) relançar o instalador sem "--feature archive", a instalação é substituída pelo binário padrão do Rusk. A máquina ainda pode continuar rodando, conectar com peers e avançar em altura de bloco, porém deixa de oferecer a funcionalidade de archive que as aplicações estavam usando.

é essa a parte que ficou martelando.

O Dusk reduz o risco do upgrade baixando e verificando binários substitutos antes de parar o Rusk. Ele também deixa o serviço parado depois, para o operador revisar a configuração gerada antes de colocá-la novamente online.

Mas a automação não consegue decidir quais configurações antigas e customizadas continuam válidas. O Dusk especificamente avisa os operadores a comparar o rusk.toml anterior e reaplicar apenas as configurações que ainda precisam, não copiar o arquivo inteiro antigo por cima da nova configuração.

Então uma instalação bem-sucedida não é a mesma coisa que um serviço corretamente restaurado.

Gerar configuração deixa os upgrades de nós no Dusk mais limpos e seguros, ou manter a função pretendida do nó é o mais importante item de verificação do operador?

#dusk @Dusk k $DUSK

O que mais importa depois de um upgrade de nó no Dusk?