Trident: Ne revient pas après la journalisation "Erreur lors de l'identification du scénario de mise à jour".

Bonjour @takuhiro ,

Merci pour cette requête.
Le fait de ne pas obtenir currentInstalledTridentVersion et tridentK8sConfigVersion des déploiements existants ou du daemonset signifie que quelque chose ne va pas, par exemple cette information n'est pas définie correctement, manquante, a été tempérée, peut-être que le déploiement et le daemonset ne sont pas présents, fondamentalement, quelque chose ne va pas.

L'idéal serait de recréer ces objets. Maintenant, il y a deux variables vides ici :

1. tridentK8sConfigVersion , lorsqu'il est renvoyé vide, Trident ne parvient pas à identifier s'il s'agit d'un scénario de mise à niveau ou non. Ainsi, dans ce scénario, votre installation Trident n'est pas marquée pour la mise à niveau ( ici ).
2. currentInstalledTridentVersion , cette variable est utilisée pour définir la version dans le statut CR, et utilisée exactement une fois dans le fichier installer.go pour comparer la version existante du trident avec la version du trident offerte par l'image ( ici ). Dans ce scénario, cette condition doit échouer et marquer Trident pour réinstallation.

On s'attend ici à ce que la réinstallation répare automatiquement le déploiement et l'ensemble de démons de sorte que lors de la prochaine itération, les informations de version puissent être correctement récupérées.

@ntap-arorar Merci pour la réponse détaillée. J'ai compris la logique lorsque tridentK8sConfigVersion et currentInstalledTridentVersion sont vides et cela serait résolu à la prochaine itération.

Dans notre cas, le message d'erreur complet était celui-ci. (Je suis désolé, j'aurais dû inclure le contexte en premier.)

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

L'erreur unable to get list of deployments a été commise ici . La cause principale de l'erreur était probablement une erreur de requête GET temporaire à api-server here , ce qui pourrait entraîner une réinstallation inutile. Dans ce cas, je pense qu'il serait préférable de revenir et de réessayer à la prochaine itération.

Je pense qu'il est possible de rendre cette logique plus résistante aux réinstallations involontaires en raison de problèmes temporaires (faux positifs) dans l'environnement Kubernetes. Cela dépend du type d'erreur renvoyé, sinon l'opérateur risque de manquer la guérison de véritables installations Trident qui sont en mauvais état.

Je suis d'accord que l'erreur doit être gérée par le type d'erreur. Si le type d'erreur représente des problèmes temporaires, le contrôleur peut ignorer la réinstallation car l'erreur sera bientôt résolue lors de la prochaine itération.

Ce problème est résolu avec le commit bf43f8 et est inclus dans la version Trident 21.10.0.