Pour gérer vos consentements :
Categories: Composants

OpenStack assouplit sa politique de saut de version

Comment composer avec la réalité d’une communauté susceptible d’avoir du mal à s’impliquer sur du long terme ? Le projet OpenStack s’est interrogé à ce sujet, entre autre questions liées à la perspective d’un ralentissement de la cadence des mises à jour.

En l’état, on est sur une release majeure tous les six mois. La dernière – nom de code Zed – vient de sortir. OpenStack ne teste officiellement que les upgrades entre versions consécutives. Dans le cas où on en « saute » certaines, le processus est plus laborieux. Entre autres parce qu’il exige de déployer en partie les moutures intermédiaires, potentiellement jamais testées dans certains environnements.

À l’origine de cette réflexion sur le changement de cadence, il y a des commentaires de sous-projets et d’implémenteurs. Qui considèrent que tenir un rythme semestriel est difficile, voire infaisable ou indésirable. Plus encore dans les grands environnements, où on se retrouve à amorcer un upgrade alors que le précédent est à peine achevé.

Allonger le cycle, pourquoi pas, mais, il ne faut pas, d’une part, trop faire attendre les « rapides ». Et de l’autre, prendre le risque de voir la communauté se détacher du projet à défaut de pouvoir s’engager sur de trop grandes fenêtres.

OpenStack instaure un cycle annuel en parallèle du semestriel

La solution retenue s’appelle SLURP. Pour « Skip Level Upgrade Release Process ». Elle maintient le rythme de deux releases par an. Elles seront toutefois alternativement « SLURP » et « non SLURP ». OpenStack continuera à tester la migration entre versions consécutives. Mais il fera de même pour la migration entre « versions SLURP » – avec un an d’écart, donc.

Le système doit entrer en vigueur avec la prochaine mouture majeure (Antelope), attendue pour mars 2023. Le cycle de vie d’OpenStack se présentera alors comme suit (EM = support étendu).

OpenStack table sur une adoption plus importante des « versions SLURP ». Et, par voie de conséquence, sur un plus grand élan communautaire.

Les sous-projets devront veiller à n’introduire aucun changement obligatoire dans une version susceptible d’être « sautée ».

Photo d’illustration © Krischam – Fotolia

Recent Posts

IA générative : l’Autorité de la concurrence pointe de sérieux risques

Dans un avis consultatif, l'Autorité de la concurrence a identifié les risques concurrentiels liés à…

2 jours ago

OpenAI signe un accord de contenu avec Time

OpenAI signe un « partenariat de contenu stratégique » avec Time pour accéder au contenu…

2 jours ago

Atos : David Layani (Onepoint) veut sortir du capital

Au lendemain du rejet de sa proposition de restructuration, David Layani annonce sa démission du…

2 jours ago

Évaluer les LLM, un défi : le cas Hugging Face

Après un an, Hugging Face a revu les fondements de son leaderboard LLM. Quels en…

3 jours ago

Mozilla face au dilemme de la GenAI dans Firefox

Mozilla commence à expérimenter divers LLM dans Firefox, en parallèle d'autres initiatives axées sur l'intégration…

3 jours ago

VMware tente d’orienter vers VCF les déploiements pré-Broadcom

VMware met VCF à jour pour y favoriser la migration des déploiements qui, sur le…

4 jours ago