Descreva o erro

A implantação do trident-csi estava travando devido a

I1207 08:20:13.609384 1 connection.go:186] GRPC error: rpc error: code = FailedPrecondition desc = Trident initialization failed; error attempting to clean up snapshot snapshot-SOMEUUID from backend ontapnas.... : error reading volume size: flexvol trident_pvc_SOMEOTHERUUID not found

Por algum motivo, o trident-csi estava seguindo as referências restantes a um instantâneo em um back-end de PVC que não suportava instantâneos.
O instantâneo em si não existia mais para esse PVC (pode ter sido criado por engano no kubernetes no passado [> 1 mês atrás]). Eu até tinha deletado o PVC original. Mas o verdadeiro problema era que excluir o objeto "volumesnapshot" para esse instantâneo não parecia excluir todas as outras referências a ele.

O back-end era "ontap-nas-economy" ( https://netapp-trident.readthedocs.io/en/latest/kubernetes/operations/tasks/backends/ontap/drivers.html , o q-tree).

Parecia que o CSI estava tentando localizar um instantâneo para um PV (qtree) provisionado em um backend 'econômico', mas na verdade estava verificando o volume pvc no backend ontap-nas regular. Que é definido como nosso padrão também. Suspeito que esse problema tenha acontecido porque a classe de armazenamento padrão era a econômica, quando o instantâneo foi criado. Isso mudou mais tarde para definir o padrão para ontap-nas que suporta back-end, mas as referências provavelmente foram quebradas/não limpas adequadamente naquele ponto (?).

Essas outras referências incluem:

• um VolumeSnapshotContent que fazia referência ao mesmo snapshot/pvc.
• um objeto TridentVolume referenciando aquele PVC excluído
• um TridentTransaction que também continha uma referência a esse instantâneo.

A exclusão das referências anteriores corrige o problema.

Estado inicial:

Algum tempo atrás, um recurso volumesnapshot foi criado para um back-end que não o suportava. A exclusão desse volumenapshot não pareceu excluir as referências a ele em outros objetos trident crd.

O que desencadeou o bug:

Reiniciando alguns nós, reiniciei o kubelet em um dos nós que tinha o volumeattachment para o snapshot/pvc.

Ambiente
Turno aberto 4.6.*

• Versão Trident: 20.07.1 (também travou em 20.10.0 após a atualização)
• Sinalizadores de instalação do Trident usados: --debug
• Tempo de execução do contêiner: cri-o://1.19.0-24
• Versão do Kubernetes: v1.19.0
• Orquestrador do Kubernetes: Openshift 4.6.*
• Gates de recursos habilitados para Kubernetes: [por exemplo, CSINodeInfo]
• SO: Red Hat Enterprise Linux CoreOS 46.82
• Tipos de back-end da NetApp: [por exemplo, CVS para AWS, ONTAP AFF 9.5, HCI 1.7]

Reproduzir

• Defina o back-end de armazenamento padrão para um que não dê suporte a instantâneos.
• Crie um objeto volumesnapshot para um back-end que não oferece suporte a instantâneos
• Altere o SC padrão para um que suporte instantâneos
• Excluir o volumenapshot
• Reinicie o nó que continha o anexo para esse instantâneo.
• Após reiniciar o nó, reinicie o pod trident-csi.
• Verifique se todas as referências estão apagadas.

Comportamento esperado

Nenhum crashlooping em referências TridentTransaction quebradas.
Imprima um aviso e continue OU limpe a referência quebrada OU adicione um sinalizador para ativar/desativar esse comportamento.