Cycle de vie Red Hat Ansible Tower

Mis à jour -

Cycle de vie de Red Hat OpenStack Platform Director

Aperçu général

Red Hat OpenStack Platform Director est :

  • lié au calendrier de sortie de Red Hat OpenStack Platform
  • pris en charge pour la même durée que Red Hat OpenStack Platform Core
  • a une compatibilité rétractive avec une version Red Hat OpenStack Platform Core

Red Hat OpenStack Platform director

Red Hat OpenStack Platform Director est un outil utilisé pour installer et gérer le déploiement et le cycle de vie de Red Hat OpenStack Platform 7 ou versions supérieures. Il est ciblé particulièrement pour l'utilisation d'opérateurs Cloud quand les mises à jour, les mises à niveau ou quand le contrôle de l'infrastructure sont cruciaux pour les opérations OpenStack sous-jacentes. Il fournit également un framework basé API d'introspection de matériel, d'allocation de services et de gestion de la pile d'OpenStack Platform.

Dans ce document, nous allons diviser Red Hat OpenStack Platform en deux parties :

  • Core : composants OpenStack principaux (Nova, Neutron, Ironic, etc)
  • Director : outil de gestion du déploiement

Pour plus d'informations sur les installateurs de Red Hat OpenStack Platform, veuillez consulter Installer et Gérer Red Hat OpenStack Platform.

Calendrier de diffusion

Red Hat OpenStack Platform Director est basé sur le projet en amont qui s'appelle TripleO et son calendrier de diffusion est donc lié au calendrier de ce produit Core.

Red Hat OpenStack Platform Director sort en même temps que Red Hat OpenStack Platform Core.

Qu'est-ce qui sera inclus dans les versions majeures et dans les versions de maintenance ?

Versions majeures

Une version majeure de Director sortira à chaque version majeure Core et représente le moyen officiel de déployer Red Hat OpenStack Platform avec le support Red Hat. Ces versions majeures ajoutent des fonctionnalités pouvant avoir une grande incidence sur la façon dont Red Hat OpenStack Platform est déployée, avec un accent sur les dernières fonctionnalités de Core. Les nouvelles versions majeures peuvent introduire différentes API, ce qui est documenté au moment de la sortie.

Chaque version de Director autorise des mises à niveau entre les versions majeures de Red Hat OpenStack Platform qui se suivent (par exemple, Director version 9 pourra mettre à niveau la version 8 à la dernière version 9).

Notes de sortie Maintenance

Les notes de sortie de maintenance ont généralement lieu après la version GA d'un produit, et elles procurent des correctifs de bogues et des améliorations en terme de performance. Ces notes de sortie n'ajoutent normalement pas de nouvelles fonctionnalités (exceptions selon les cas). Cela signifie que la possibilité d'endommager les API est réduite, ainsi que les besoins de migrations de bases des données et autres changements majeurs.

Chaque version de Director permet des mises à jour mineures automatisées sur place entre les versions de maintenance pour obtenir le contenu le plus récent. Ces mises à jour sont gérées par une procédure de propagation (ou « rolling ») - en mode HA, pendant que tous les autres services OpenStack sont encore en cours d'exécution.

Support Cycle de vie

Red Hat OpenStack Platform Core suit les cycles OpenStack en amont de prêt : tous les 6 mois, il y a une nouvelle version OpenStack (nommée Juno, Kilo, Liberty etc.) qui est ensuite suivie d'une version productisée (6 pour Juno, 7 pour Kilo, etc.).

Red Hat OpenStack Director a aligné son Support de cycle de vie à celui du produit Core.

Pour plus d'informations, veuillez consulter le Support Red Hat OpenStack Platform. (1)

(1) Red Hat OpenStack Platform Director a un plus petit cycle de vie que pour les versions 7 et 8. Depuis la version 9, Director a aligné son cycle de vie avec Core et a appliqué ce changement rétrospectivement aux versions 7 and 8. Toutes les versions de Red Hat OpenStack Platform Director sont donc alignées sur celles du produit core maintenant.

Rétrocompatibilité

Red Hat OpenStack Platform Director peut déployer et gérer une ancienne version majeure de Red Hat OpenStack Platform Core. Le but principal de cette fonctionnalité est de gérer les mises à niveau de l'ancienne version à la version en cours en toute sécurité.

Par exemple, la fonctionnalité Red Hat OpenStack Platform Director 9 est capable de déployer, mettre à échelle, et mettre à jour Red Hat OpenStack platform Core 8. De plus, elle peut mettre à niveau à la même version que Director (par ex. passer de core 8 à la dernière version 9) .

Intégration avec d'autres produits

Les produits qui veulent s'intégrer à Director doivent cibler leurs fonctionnalités par rapport aux API majeures. Les API standards OpenStack sont : nova, ironic, etc., il n’y a pas d'API privée dans Director. Le versionnage et la dépréciation d'API s'alignent sur les politiques OpenStack en amont (2), plus les rétro-portages que nous décidons de mettre en place. Ceux-ci seront expliqués dans les notes.

Comme Director et Core vont sortir en même temps, la question du timing ne se pose pas.

Cloudforms est un exemple d'une telle intégration utilisant les API notées ci-dessus pour permettre une gestion d'infrastructure à partir de là. Comme ils utilisent les API standards, l'intégration devrait se passer sans problèmes et les cycles de développement peuvent demeurer découplés.

(2) http://developer.openstack.org/api-ref.html

Interchanger les outils de gestion et de déploiement

Les principaux cas d’utilisation de Director est de gérer le 1er jour (déploiement initial) et le 2ème jour (mises à niveau, scale-up, etc.). Si vous souhaitez utiliser Director pour la gestion du 2ème jour, tout doit être fait par le biais de Director ou en utilisant les API de Director. Il n’y a aucun moyen raisonnable pour Red Hat de concilier les modifications manuelles effectuées en dehors de Director, et sans cette réconciliation, les possibilités d’évolubilité, de mises à jour ou mises à niveau, sont complètement perdues par notre ensemble d’outils pris en charge (Director).

Si vous choisissez d’utiliser Directeur UNIQUEMENT le 1er jour (déploiement initial) et gérer le 2ème via d’autres moyens, vous perdez la capacité de Director à effectuer toute opération le 2ème jour. Une fois que tous les outils en dehors de Director sont utilisés, toute nouvelle opération doit alors être orchestrée manuellement pour les questions de gestion du changement, d'évolubilité, de mises à jour et mises à niveau. Les méthode manuelles peuvent vous informer comment ces orchestrations sont implémentées dans Director, vous informer les meilleures pratiques afin que vous puissiez le faire vous-même, mais les scripts/outils que vous utilisez pour ce faire seront autonomes (ou Consulting pris en charge).

L'intégration d'outils de tierce partie qui appellent les API de Director est prise en charge et ne compromet pas le support des opérations au 2ème jour via Director. L'intégration entre Red Hat Openstack director et Red Hat Cloudforms en est un exemple.

Commentaires

Vos commentaires sont toujours bienvenus. Veuillez contacter les Responsables produits de Director pour clarifier vos questions ou pour qu'ils puissent vous expliquer comment le cycle de vie du produit peut affecter vos clients ou produits.