Introdução do Time Voyager
Quando você confirma um blueprint encenado (implemente atualizações na rede), o resultado pode não ser o que você esperava. Talvez você tenha cometido mudanças em um modelo por engano e você quer desfazer essas mudanças. Ou talvez você tenha decidido devolver a rede ao estado que estava em várias revisões atrás. Dependendo do nível de complexidade, organizar e comprometer mudanças manualmente para desfazer o que você fez pode ser difícil e propenso a erros. Nesses casos, você vai querer usar o Time Voyager para restaurar rapidamente as revisões anteriores de um blueprint.
Você pode reverter um modelo para qualquer revisão retida. Os 5 compromissos de blueprint mais recentes são retidos por padrão. Quando você confirma uma sexta vez, a primeira revisão é descartada, e a sexta revisão torna-se a quinta, a segunda revisão torna-se a primeira, e assim por diante, à medida que mudanças adicionais no blueprint são comprometidas. Você pode alterar o número de revisões salvas automaticamente para até 100 revisões (a partir da versão 4.2.0 do Apstra). No diálogo Commit , uma mensagem permite que você saiba que se você atingiu o seu limite e confirmar outra mudança, a nova revisão substituirá a revisão automática mais antiga. Se você chegou ao limite quando quiser se comprometer e não quiser que nenhuma revisão seja excluída, você pode fechar o diálogo de confirmação sem se comprometer e aumentar o número de revisões salvas automaticamente no Time Voyager.
Você pode reter uma revisão em particular indefinidamente mantendo-a , ou salvando-a manualmente. Quando você mantém uma revisão, ela não está incluída nas 5 revisões que ciclo fora. Você pode acompanhar até 25 revisões, tendo efetivamente 30 revisões de blueprint para escolher, por padrão. (Se você alterar o número de revisões salvas automaticamente para o máximo de 100, você pode economizar até 125 revisões.) Tenha em mente que cada revisão requer espaço de armazenamento. Se você decidir que não deseja mais manter uma revisão, você pode simplesmente deletá-la.
Ao comprometer um blueprint, recomendamos que você adicione uma descrição de revisão para ajudar a identificar as mudanças feitas nessa revisão. Essas descrições são exibidas na seção de história de revisão do modelo, desde que essa revisão seja retida. Se você não adicionar uma descrição quando se comprometer, você sempre pode adicionar um depois (mas você precisará lembrar quais foram as mudanças). Ao pular para uma revisão (voltando), esta descrição ajuda você a escolher a correta. As diferenças específicas entre as revisões não são exibidas, de modo que a descrição é a única informação de mudança disponível para essa revisão.
Ao pular para uma revisão, quaisquer mudanças anteriormente encenadas que não tenham sido cometidas são descartadas. Se este for um problema, não reverta até que você tenha abordado as mudanças não comprometidas.
O Time Voyager não é apenas uma função de desfazimento. Ao usar o Time Voyager, você volta para um compromisso anterior. Isso significa que qualquer coisa excluída no último commit é novamente aplicada ao reverter. Pode haver muitas mudanças entre revisões, adições e remoções, todas as quais seriam incluídas na reversão. Antes de se comprometer com uma reversão, é importante que você analise detalhadamente as alterações pendentes. O Time Voyager é melhor comparado com um sistema de controle de revisão (para toda a rede!) do que uma função de desfazimento.
Cenários do Time Voyager sem suporte
- Depois de atualizar o servidor Apstra, você não pode pular para um blueprint com uma versão mais antiga porque o histórico de revisão do blueprint é descartado no upgrade. Se você precisar retornar a uma versão anterior do Apstra que foi tomada antes de atualizar o Apstra, consulte o Banco de dados de restauração. Esse método pode causar problemas do ponto de vista da configuração do dispositivo.
- Não é suportado quando a configuração Pristine mudou entre as revisões.
- Não é suportado quando as versões nos são diferentes entre revisões. Você pode rebaixar a versão nos para a mesma versão usando o gerenciador de dispositivos e depois reverter para uma revisão anterior.
- Dispositivos que foram alocados em uma revisão anterior que não estão mais disponíveis resultam em que a ID do sistema de erro de construção não existe. (Por outro lado, adicionar um dispositivo e pular para uma revisão anterior sem que esse dispositivo seja bem sucedido. O dispositivo adicional será removido.)
- Recursos que foram atribuídos em uma revisão anterior que foram reatribuídas causam o recurso de erro de construção já em uso. Para resolver o erro de construção, atribua recursos manualmente a cada membro desse grupo ou reinicie as substituições do grupo de recursos. (Pular para uma revisão anterior depois que um pool de recursos global anteriormente atribuído é modificado pode ser bem sucedido, mas pode causar uma violação de intenção.)
- Não é compatível se as alterações manuais de configuração do dispositivo tiverem sido aceitas.
- Não é suportado em nenhum outro caso em que o estado de configuração do dispositivo resultante seja diferente.
Por que não usar o backup/restauração do servidor Apstra para fazer uma revisão anterior? O Time Voyager mantém a configuração sincronizada entre o servidor e os dispositivos Apstra (o máximo possível); O backup/restauração do Apstra não. Efetivamente, o backup/restauração do Apstra é uma mudança fora de banda do ponto de vista da configuração do dispositivo. Se um backup for restaurar, você precisaria fazer uma configuração completa para garantir que a configuração do dispositivo reflita o que você restaurou do backup do banco de dados. Isso provavelmente seria disruptivo.
A partir do blueprint, clique em Time Voyager para ir às revisões de blueprint retidas. A primeira revisão da lista é a ativa. Revisões sucessivas são ordenadas por data da mais recente para a mais antiga. 