Red Hat OpenShift AI

Pourquoi OpenShift se sépare de l’Operator SDK CLI

Lors du lancement de Red Hat OpenShift 4.16, l’éditeur a émis un avis de dépréciation pour l’interface en ligne de commande du kit de développement logiciel pour les opérateurs (SDK CLI) livré avec OpenShift. Des questions se posent sur la prise en charge du SDK et la manière avec laquelle futures versions de l’opérateur fonctionneront sur les nouvelles versions d’OpenShift.

L‘avis de mise au placard a été publié dans la documentation officielle. L’objectif de Red Hat est de découpler le SDK de l’opérateur du cycle de vie d’OpenShift dans une future version et de se concentrer sur la maintenance à long terme du binaire CLI.

La filiale d’IBM évoque plusieurs raisons pour lesquelles le CLI a été découplé du SDK de l’opérateur d’OpenShift, à commencer par l’évolution des API Kubernetes, qui s’est stabilisée.

Ensuite, le code de base n’a pas beaucoup changé entre les versions d’OpenShift. Pour les projets d’opérateurs basés sur Ansible et Helm, le développement se fait entièrement en dehors du CLI du SDK après la création initiale du projet et des API. Ce qu’il reste à faire, explique Red Hat, c’est mettre à jour les bibliothèques de gestion des contrôleurs pour les opérateurs Golang et assurer le packaging et les tests d’un opérateur.

Enfin, l’adoption et la connaissance du modèle d’opérateur ont atteint un point dans l’écosystème Kubernetes où l’espace problématique est désormais bien compris. Par conséquent, la plupart des demandes de fonctionnalités pour le SDK concernaient l’utilisation de nouvelles images et bibliothèques pour les opérateurs basés sur Helm et Ansible afin de résoudre les vulnérabilités de sécurité dans les packages installés, plutôt que de nouvelles fonctionnalités pour le CLI du SDK.

Dans le projet en amont, Red Hat annonce avoir commencé à séparer le type d’opérateur Ansible dans son propre dépôt. Le SDK de l’opérateur Helm restera une partie du SDK de l’opérateur et continuera d’être une option viable pour écrire des opérateurs pour OpenShift et le plus large écosystème Kubernetes.

À long terme, OLM v1 sera capable de réconcilier les charts Helm réguliers de manière optimale, rassure l’éditeur.

Bonne nouvelle, vous avez un peu de temps devant vous. Le cycle de support de trois ans d’OpenShift 4.16 et 4.18 s’applique également au SDK de l’opérateur, il n’est donc pas nécessaire d’agir immédiatement. Tous les détails sont expliqués (en anglais) dans cet article.

Retour en haut