OpenStack va simplifier le basculement entre des versions majeures non consécutives, avec les mêmes garanties de stabilité que sur le cycle actuel.
Comment composer avec la réalité d’une communauté susceptible d’avoir du mal à s’impliquer sur le long terme ? Le projet OpenStack s’est interrogé à ce sujet, entre d’autres questions liées à la perspective d’un ralentissement de la cadence des mises à jour.
En l’état, on est sur une Libération majeure tous les six mois. La dernière – nom de code Zed – vient de sortir. OpenStack ne teste autre que les mises à niveau entre versions consécutives. Dans le cas où on en « saute » certains, le processus est plus laborieux. Entre autres parce qu’il exige de réussir 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 renvoie que tenir un rythme semestriel est difficile, voire infaisable ou indésirable. Plus encore dans les grands environnements, où on se retrouve à amorcer un mise à niveau 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 semestre
La solution retenue s’appelle SLURP. Pour « Skip Level Upgrade Release Process ». Elle confirme le rythme de deux libère par an. Elles seront alternativement « SLURP » et « non SLURP ». OpenStack a décidé de tester la migration entre les 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).
Table OpenStack sur une adoption plus importante des « versions SLURP ». Et, par voie de conséquence, sur un plus grand élan communautaire.
Les sous-projets doivent veiller à n’introduire aucun changement obligatoire dans une version susceptible d’être « sautée ».
Photo d’illustration © Krischam – Fotolia
