Trident: No regresa después de registrar "Error al identificar el escenario de actualización".

Hola @takuhiro ,

Gracias por esta consulta.
Si no se obtienen currentInstalledTridentVersion y tridentK8sConfigVersion de implementaciones o daemonset existentes, significa que algo está mal, por ejemplo, esta información no está configurada correctamente, falta, se ha modificado, posiblemente tanto la implementación como el daemonset no están presentes, básicamente, algo está mal.

Lo ideal sería volver a crear estos objetos. Ahora hay dos variables vacías aquí:

1. tridentK8sConfigVersion , cuando se devuelve vacío, Trident no puede identificar si se trata de un escenario de actualización o no. Entonces, en este escenario, su instalación de Trident no está marcada para actualización ( aquí ).
2. currentInstalledTridentVersion , esta variable se usa para configurar la versión en el estado CR y se usa exactamente una vez en el instalador.go para comparar la versión existente del tridente con la versión del tridente que ofrece la imagen ( aquí ). En este escenario, esta condición debería fallar y marcar Trident para su reinstalación.

La expectativa aquí es que la reinstalación repararía automáticamente la implementación y el daemonset de modo que en la siguiente versión de iteración la información se pueda recuperar correctamente.

@ntap-arorar Gracias por la respuesta detallada. Entendí la lógica cuando tridentK8sConfigVersion y currentInstalledTridentVersion están vacíos y eso se resolvería en la siguiente iteración.

En nuestro caso, el mensaje de error completo fue este. (Lo siento, debería haber incluido el contexto primero).

time="2021-06-26T14:56:52Z" level=error msg="Error identifying update scenario." controllingCR=trident err="unable to get list of deployments"

El error unable to get list of deployments se cometió aquí . La causa raíz del error probablemente fue un error de solicitud GET temporal al servidor API aquí , lo que podría provocar una reinstalación innecesaria. En este caso, creo que sería mejor regresar y volver a intentarlo en la siguiente iteración.

Creo que existe la posibilidad de hacer que esta lógica sea más resistente a las reinstalaciones no deseadas debido a problemas temporales (falsos positivos) en el entorno de Kubernetes. Esto depende del tipo de error que se devuelva; de lo contrario, el Operador puede fallar en la curación de las instalaciones reales de Trident que están en mal estado.

Acepto que el error debe ser manejado por el tipo de error. Si el tipo de error representa problemas temporales, el controlador puede omitir la reinstalación porque el error se resolvería pronto en la siguiente iteración.

Este problema se solucionó con la confirmación bf43f8 y se incluye en la versión Trident 21.10.0.