Caso seja preciso, é possível parar a atualização dos jobs, deletando-os diretamente no cluster (# kubectl -n c2a7dv delete job <<nome do job>> ). Porém, ao executar este processo deverá ser avaliado o que o mesmo executará. Um exemplo é o caso do “migration” (upddistr), ao deletar este job deveremos realizar a geração dos flags de controle de execução dos pods (# touch /volume/flags/<<filename>>). Além disto, temos que garantir que os demais processos foram executados. Caso durante o processo de atualização, quebre o UPDDISTR. Devemos entrar no volume do ambiente e verificar o erro gerado dentro do UPDDISTR.LOG que fica na pasta /volume/logs. Neste momento temos algumas ações: - Se o problema for de usuário e senha. Basta reiniciar o pod do upddistr para reiniciar o processo. Isto ocorre devido a falta de conectividade com o HLCLOUD. Caso seja preciso, acionar o time de FRAMEWORK para avaliar o HLCLOUD.
- Se o problema for na criação de campos/índices disponibilizados recentemente. Recomendo abortar o processo e identificar o módulo responsável pelo campo para ajustar no ATUSX. INFORMAR o time de GCAD sobre o erro.
- Se o problema for em campos/índices já existentes, direcionar a ocorrência para o time de banco de dados da engenharia avaliar. Neste caso, recomendo abortar a atualização até o ajuste do banco pelo time.
- Se for processos de infraestrutura, devemos atuar pontualmente e reiniciar o processo.
- Se o problema for em algum RUP, temos duas opções.
- Alterar o deployment do cronjob de migrator e adicionar o sleeper no command (# kubectl -n c2a7dv edit cj protheus-updater)
- Copiar o novo RPO para dentro do pod do cronjob (# kubectl -n c2a7dv cp tttm120.rpo c2a7dv/protheus-updater-xxxxx:protheus/apo/tttm120.rpo)
- Executar o init-upddistr diretamente dentro do pod(# init-upddistr)
- Retirar o rup do RPO e executar o processo na mão
- Abortar o processo e fazer o rollback no banco de dados.
Para todos os casos citados acima, recomendo realizar todo o troubleshoot antes de acionar os times responsáveis por cada artefato. Para todos os casos que envolvem rollback de dados, coletar os logs de erro, realizar o processo citado no item Restore de dados e enviar os logs para o time de gestão de dados. Caso o problema identificado seja na atualização do HELM: Falta de imagem, falta de recurso ou quaisquer problemas de infra, realizar a análise do motivo do erro estar ocorrendo. Nesta situação temos a possibilidade de executar o helm upgrade na mão. Basta alterar o ns, informando a versão desejada (UpdateDesiredVersion) e criar o job de atualização na mão | 