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