Mon chef voulait qu'on fasse un article de blog sur notre expérience de la migration, mais vu que y a 2 commandes donné dans la FAQ et le reste marche pareil, on a pas réussi à trouver de quoi faire un article intéressant (genre, même pas "on a pu rajouter un correctif de bug" vu qu'on a pas eu de bugs).
Je vois vraiment pas trop pourquoi partir sur les dérivés qui vont avoir les mêmes paquets, mais avec au mieux, un délai dans les correctifs de bugs, au pire, un différentiel sans la majorité des devs pour s'en occuper.
Tu veux dire que tu as migré vers l'un des sus-nommé ou vers Stream ?
Je serais intéressé d'un retour d'expérience d'une entreprise qui utilise une rolling release en prod, chaque fois que j'ai suggéré l'idée dans mes employeurs précédent j'ai assisté à une grande levée de boucliée mais sans réel argument pertinent. Il est facile de séparer OS de base et applis critiques , de faire pointer des environnements différents sur des snapshots différents des repos, d'automatiser des suites de tests.
Tu veux dire que tu as migré vers l'un des sus-nommé ou vers
Stream ?
Vers Stream
Je serais intéressé d'un retour d'expérience d'une entreprise
qui utilise une rolling release en prod, chaque fois que j'ai
suggéré l'idée dans mes employeurs précédent j'ai assisté à
une grande levée de boucliée mais sans réel argument
pertinent. Il est facile de séparer OS de base et applis
critiques , de faire
pointer des environnements différents sur des snapshots
différents des repos, d'automatiser des suites de tests.
Alors vu mon employeur, le mandat de mon équipe et surtout la taille du parc et de l'équipe que je soit un bon exemple.
Mais je pense aussi qu'appeler Centos 8 une "rolling release", c'est comme dire qu'un avion est une automobile parce que ça peut se déplacer sur une route.
Centos 8 a des tests de QA automatisé, une promesse de compatibilité binaire via RHEL, et une politique de ne pas mettre à jour de façon disruptive. C'est ni Rawhide, ni Debian Unstable ou les devs vont mettre à jour sur la derniére version d'upstream, dont le but est de preparer la prochaine stable, etc.
Centos 8 stream est déjà stable (au sens figé), et la seule différence avec avant, c'est d'avoir les mises à jours de sécurité et de bugfix au fil de l'eau, donc de ne pas attendre que RHEL fasse une release, ce qui est pour moi un bonus.
Si un bug passe dans Centos Stream 8, le bug aurait fini par arriver dans la version stable mais plus tard, il y a pas de magie. Et vu que Centos n'a pas de support pour les versions mineurs autre que la dernière, tu es quand même obligé de mettre à jour pour la sécurité. Prendre une version mineur et appliquer les correctifs 1 par 1, c'est ni supporté, ni supportable, vu que tout est construit en visant les derniers RPMs. Ça marche sans doute plus parce que les paquets ont des modifs minimums plus que par un design particulier de la distro.
Ensuite, la ou je peux imaginer qu'une rolling release importen, c'est ce qui est hors de la distribution. Par exemple, le kernel ne garanti pas son ABI (même dans les LTS, etc), donc les gens qui dépendent de drivers externes ont sans doute peur de soucis (souci qui existe deja de base avec une mise à jour de sécurité avant, vu que l'ABI est toujours non garanti).
De même, Centos ne va tester que la distribution, si un produit proprio externe dépend d'un truc non documenté, ça peut casser. Mais pareil, ça aurait fini par casser à tout moment lors d'une mise à jour de sécurité.
Donc moi, j'ai ni l'un, ni l'autre, donc quand on m'a dit "tu vpeux avoir des bugfixes plus vite, et faire des PR plutot que d'aller faire chier les products managers/owners", j'ai dit "banco".
Sûr pour l'instant ça n'a pas trop dérivé mais l'idée derrière c'est qu'il n'y aura pas une centos 8 stream puis une centos 9 stream. C'est Centos stream rolling release. Ce qui veut dire que tôt ou tard ils vont introduire des trucs qui pète.
Prenons un exemple: la syntaxe des fichiers de configs des containers lxc a changé entre ubuntu 16.04 et ubuntu 18.04. Quand la 16.04 était sur le point d'arriver en fin de vie on a upgradé un certain nombre de machines, dont des hyperviseurs LXC et on a eu besoin de migrer ces fichiers de config. Sur une rolling release tu n'as pas cette délimitation de version, à un moment donné ton app doit passer de version majeur introduisant des changement. Tu as le choix:
- d'informer les utilisateurs du changement et espérer pour eux qu'ils lisent les news pour ne pas péter leur distro (j'avais par exemple pété une archlinux en faisant un pacman -Syu sans m'informer avant il y'a quelques années quand ils ont dépréciés la séparation /bin /usr/bin).
- d'avoir des scripts blindés qui prennent en charge tous les cas de figures. C'est parfois très difficile voire impossible.
Donc tôt ou tard ça arrivera sur Centos Stream. Je ne parles pas forcément de péter sa distro mais ça peut être simplement un changement d'une version majeure d'une application qui a déprécié depuis déjà n versions certaines syntaxes de ses fichiers de configuration et qui du jour au lendemain refuse de démarrer après une upgrade. Avec un parc correctement géré, des séparations d'environnements et des tests ad-hoc ce n'est pas la fin de monde, mais c'est une façon différente de gérer sa distro qu'avec le modèle de versions majeures dures qui aspirent à ne casser aucune compatibilité durant tout le cycle de vie.
"Around the time the RHEL 9 Public Beta is issued, an additional set of CentOS Stream repositories and ISOs will be available"
On ne le voit pas, mais j'ai surligné en flu "additional" sur mon écran :p
Donc quand le système passes de Centos 8 à Centos Stream 8, pas grand chose ne change, et il n'y a pas de migration magique vers Centos Stream 9 quand CS9 est dispo (la preuve, c'est dispo, et j'ai encore des CS8 en prod).
Et Centos Stream 8 est supporté jusqu'à la fin mai 2024, cf le site.
Ensuite, prendre Centos Stream 9 en production pour le moment (cad avant la release de RHEL final), c'est en effet autre chose. D’expérience, la bêta ne va pas avoir des changements énormes, et on a prévu d'en installer une sur un hyperviseur (parce que YOLO). Mais le matos vient juste d'être livré, donc je peux pas dire grand chose avant quelques semaines.
A titre perso, j'ai un pc qui me sert de serveur que j'ai installé avec une version beta de RHEL 7 (comme un goret en prenant la tour au bureau et en allant taper dans le miroir interne), et je me souviens pas avoir eu de souci notable à cause de ça, donc je ne pense pas que CS9 dans la phase avant la release de RHEL soit fondamentalement cassé.
Et si les gens pensent qu'il n'y a qu'un seul flux de la distro pour 8 et 9, je comprends mieux pourquoi tout le monde s'affole. J'imagine que le site web pourrait être plus clair à ce sujet.
Posté par Psychofox (Mastodon) .
Évalué à 4.
Dernière modification le 14 janvier 2022 à 16:17.
Et si les gens pensent qu'il n'y a qu'un seul flux de la distro pour 8 et 9, je comprends mieux pourquoi tout le monde s'affole. J'imagine que le site web pourrait être plus clair à ce sujet.
Ben c'est comme cela que ça avait été annoncé en fait. J'ai plus l'impression que c'est un rétropédalage pour ne pas perdre trop d'utilisateurs.
Q6: Will there be separate/parallel/simultaneous streams for 8, 9, 10, etc?
A: Each major release will have a branch, similar to how CentOS Linux is currently structured; however, CentOS Stream is designed to focus on RHEL development, so only the latest Stream will have the marketing focus of the CentOS Project.
Because RHEL development cycles overlap, there will be times when there are multiple code branches in development at the same time.This allows users time to plan migrations and development work without being surprised by sudden changes.
Specifically, since the RHEL release cadence is every 3 years, and the full support window is 5 years, this gives an overlap of approximately 2 years between one stream and the next.
Notons que la page actuelle n'a rien changée du tout avec cette formulation (lire https://centos.org/distro-faq/). Donc il n'y a pas eu de changements, c'était plutôt clair.
On voit clairement qu'il y a des branches par version majeure qui sont indépendantes entre elles.
Alors perso j'ai quelques critiques à faire sur leur annonce en terme de timing décisionnel, mais cet aspect a été je pense bien couvert dès le début. C'est difficile de faire plus clair ou de voir la confusion depuis les sources officielles (je ne parle pas des propos déformés sur d'autres sites).
Je trouve cela inquiétant si certains défendent CentOS Stream comme un ArchLinux à la sauce RHEL. Et surtout envisager de migrer sur Alma ou Rocky sans même avoir pris le temps de bien lire et réfléchir à ce qu'était CentOS Stream d'abord.
C'est dans la version 1 de la FAQ qui date de mars 2020.
C'est aussi dans la version de septembre 2020 sur archive.org, pour le cas ou il y a des doutes sur un éventuelle caviardage de l'historique du wiki.
Je rappelle aussi que l'annonce du changement de Centos 8 vers Stream date de décembre 2020, soit 9 mois après la première FAQ.
Donc à moins de supposer l'usage d'un ordinateur quantique pour voyager dans le temps (on a déjà la technologie pour dilater le temps par l'usage de slides en police taille 7, donc le reste est faisable) ou d'un complot qui implique tout le monde sauf les utilisateurs Centos, je pense pouvoir dire que c'est pas un retro pédalage.
Si un bug passe dans Centos Stream 8, le bug aurait fini par arriver dans la version stable mais plus tard, il y a pas de magie.
Ben justement : non (d'après toi, pourquoi donc RH vend le support sur RHEL et on pas Stream?).
Vous avez donc décidé d'utiliser les "release candidate", la où des bugs (y compris des regrettions) sont chopés avant d'être en stable donc avec plus de bugs que RHEL (ou Rocky Linux), en prod sans vraiment l'assumer, on a l'impression…
Ben justement : non (d'après toi, pourquoi donc RH vend le
support sur RHEL et on pas Stream?).
Je note qu'on te reconnaît à ton audace.
Mais en effet, je peux te dire pourquoi le support de mon employeur est sur RHEL et pas sur Stream, et pourquoi y a des versions stables.
Primo, c'est pour les certifications, notamment en vue de vendre au gouvernement fédéral des USA (mais pas que). Si tu veux vendre à l'armée américaine, faut que ton produit soit certifié par le NIST. Je ne connais pas le détail, mais ç'est sans doute comme les processus de certifications ISO. C'est pas forcément compatible avec la façon de faire dans le logiciel libre, et il faut donc séparer les 2. Par exemple, j'imagine qu'il y a des questions d'audit, donc d'avoir un salarié RH responsable d'avoir pris le code de la communauté (eg, un truc d'ordre legal).
Moi, je m'en fout de FIPS, et je suppose toi aussi. Mais pas certains clients, donc si les clients veulent du FIPS, il y a du FIPS. En règle général, la communauté n'en veut pas, et ne va pas se plier aux règles de certifications.
Ensuite, parce qu'il faut traduire la documentation et les logiciels, car non seulement tout le monde ne parle pas anglais, mais en plus, il y a des pays ou tu peux pas vendre au gouvernement sans ça (exemple, la loi no 94-665 du 4 août 1994 relative à l'emploi de la langue française). La traduction, ça implique aussi d'avoir une période ou les chaînes ne bougent pas, et de sortir plus tard.
Moi, je m'en fout, je parle anglais, donc je préfère ne pas attendre. Mais quand un client demande ça, tu t'adaptes.
Tertio, parce que le marketing se sert des versions stables pour faire du marketing. Envoyer des mails, présenter les fonctionnalités, inviter les clients à regarder des photos de croissants pour rappeler ce qu'on avait avant la pandémie, tout ça.
Moi, je m'en fout un peu, j'ai une boulangerie en bas de chez moi. Et la communauté du libre en général semble ne pas trop faire de marketing.
Donc il y a tout un tas d'activité d'une boite normale qui s'appuie sur l'idée d'avoir une release, mis qui sont non seulement pas important pour la plupart des utilsiateurs finaux (eg, le marketing), mais qui vont aussi rajouter de la lenteur qui ne va pas bénéficier à grand monde (FIPS et divers certifications).
Vous avez donc décidé d'utiliser les "release candidate", la
où des bugs (y compris des regrettions)
Ma foi, si tu vois un régression, n'hésite pas à montrer le bug tracker qu'on puisse en discuter sur la base des faits.
Sinon, tu es juste en train de faire du FUD a quelqu'un de visiblement mieux placé que toi sur le sujet.
sont chopés avant d'être en stable donc avec plus de bugs que
RHEL (ou Rocky Linux), en prod sans vraiment l'assumer, on a
l'impression…
Non, pour ça, j'ai des serveurs Fedora en prod, comme par exemple, une paire de firewall en HA: $ ssh masa.rht.gluster.org -l root uname -a
Linux masa.rht.gluster.org 5.14.14-300.fc35.x86_64 #1 SMP Wed Oct 20 16:14:50 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
Ou des reverses proxy en HA: $ ssh proxy01.rht.gluster.org -l root uname -a
Linux proxy01.rht.gluster.org 5.14.15-300.fc35.x86_64 #1 SMP Wed Oct 27 15:53:39 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
Mais je fait pareil avec mes serveurs perso sur mon lan: $ ssh root@git.home uname -r
5.15.12-200.fc35.x86_64
Ou hors du lan: $ ssh root@xmpp uname -r
5.14.17-301.fc35.x86_64
Et crois moi, j'ai aucun souci à mettre à jour ces machines vers les beta de Fedora, donc je pense que j'arrive pleinement à faire la différence entre une RC et une stable à l'usage.
Je ne dis pas que c'est une mauvaise distribution qui ne fonctionnera pas techniquement, mais le problème n'est pas technique justement.
C'est juste qu'il est impossible de dire "production" sur Centos Stream au client final (lui retient que c'est avant RedHat qui lui est stable/production), donc c'est forcément moins stable (peu importe la réalité de sa stabilité).
Tout n'est qu'une question d'image ici. Stream peux avoir toutes les qualités possibles, son image est:
* centos8 a été avorté en terme de support, donc manque de confiance envers RedHAt sur le sujet après pour ce qui concerne autre chose que RHEL, Stream en hérite automatiquement,
* c'est avant la RHEL/production dans son workflow, donc c'est instable/qualification. Basique.
Et c'est bien ce que souhaite RedHat je pense, qu'on arrête d'avoir une distribution "production" gratuite (qu'en plus lui paie ). C'est réussit :)
Stream n'est pas supposé être le bac à sable de RHEL ni être une Fedora Entreprise ; c'est ce que nous assure Red Hat. Après, dans son positionnement par rapport au produit final ça fait un peu la RC puisqu'on nous dit que ce n'est pas la ß…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Rappelons que CentOS (et maintenant Rocky) sont des RHEL débrandée mais sinon identiques y compris les bugs.
C'est pour moi assez trompeur de dire ça car en réalité il y a un délai (non négligeable) entre RHEL et CentOS avant.
Tu pouvais avoir un bogue dans RHEL, corrigé rapidement après et CentOS n'a pas eu la MaJ avec le bogue entre temps !
Pour moi ce raisonnement n'aurait réellement de sens que si la synchronicité entre RHEL et CentOS était de l'ordre de la journée, pas de plusieurs semaines (voire mois par moment selon les MaJ).
Du coup, si on suit le même raisonnement, à cause des délais, RHEL était la Beta de CentOS normal.
Ben si, même RH le dit:
Fedora --> CentOS Stream --> RHEL, à chaque fois des modifs / stabilisations des logiciels.
RHEL --> CentOS, que debranding.
Je ne vois pas en quoi cela signifie que CentOS Stream n'est pas stable ou est une Beta de RHEL. Être l'amont n’implique pas cela.
C'est pour cela que je dis qu'il faut voir ça plus comme une RC (et avant, c'est RHEL qui l'était pour CentOS.) La grande inquiétude pour les usagers de Stream est que rien ne garanti que ce sera toujours la même chose à l'arrivée dans RHEL ni qu'un truc ne sera pas poussé prématurément pour tester avant les clients qui payent…) Let's wait and see.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Sauf que c'est complètement con de pousser un truc "pour tester" si les gens ne savent pas qu'il y a un changement.
Le but d'un test, c'est d'avoir des retours, et pour avoir des retours, faut que les gens soient d'accord et bossent avec toi.
Personne ne va pousser un truc en se disant "yolo, ça va peut être casser la prod". Je rappelle aussi qu'il y a des tests automatisés, donc à minima, les fonctionnalités de base sont vérifiés.
Si le but est de faire des tests, le modèle d'EPEL et de Fedora avec un dépôt "testing" et des volontaires marchent largement mieux, donc pourquoi se faire chier à faire autrement vu que ça va juste apporter des emmerdes à tout le monde ?
D'ailleurs, c'est pour ça aussi qu'il y a des structures séparées, les SIG (exemple) pour justement permettre ce genre de choses. Et les SIGs ne datent pas de Stream, il y a déjà eu ça à l'époque de Centos 7.
Donc si ça ne bénéficie à personne, si il y a explicitement une structure ailleurs documenté pour faire les tests, pourquoi quelqu'un ferait le contraire ?
Tout n'est qu'une question d'image ici. Stream peux avoir
toutes les qualités possibles, son image est:
Image en partie poussé aussi par les concurents. J'ai vu assez de commerciaux pour savoir qu'ils ont aucun scrupule à ce niveau la.
centos8 a été avorté en terme de support, donc manque de
confiance envers RedHAt sur le sujet après pour ce qui concerne
autre chose que RHEL, Stream en hérite automatiquement,
Centos n'avait pas de support avant (au sens support téléphonique, tout comme au sens recevoir des bugs), donc au final, si le client découvre qu'il n'avait personne à appeler, ç'est tant mieux.
c'est avant la RHEL/production dans son workflow, donc c'est
instable/qualification. Basique.
C'est un peu du bullshit comme raisonnement, vu que personne ne va mettre des Linux Mint en prod parce que c'est après Ubuntu qui est après Debian.
Et c'est bien ce que souhaite RedHat je pense, qu'on arrête
d'avoir une distribution "production" gratuite (qu'en plus lui
paie ). C'est réussit
Si RH voulait se débarrasser de Centos, il suffisait d'attendre.
Tout les clones ont fini par s’arrêter d'eux même, et Centos elle même n'était super vivace vers 2011-2013, avec une gouvernance non transparente, etc.
Par exemple, il y a eu un délai de 6 à 7 mois entre RHEL et Centos pour les versions 6.0 et 6.1 (à comparer avec le mois pour Centos 5.0 et 5.1).
En pratique, je pense que ce que Centos a fait, c'est surtout décimer les distros concurrentes de RHEL. Vu que personne n'a les moyens d'attaquer RHEL par le haut en fournissant un produit plus prestigieux et de meilleur qualité, le seul moyen de concurrencer c'est en étant moins cher ou différent.
Sauf que faire moins cher que Centos, c’est quand même tendu.
Et faire différent, c'est pas évident non plus. Oracle a tenté, ils ont pas réussi.
Donc RH avait tout à gagner à garder Centos en vie.
Et RH a encore plus à gagner à avoir des clones actifs vu que les dits clones ont réussi à faire ce que Centos n'a jamais pu faire par design, à savoir rassembler une communauté de contributeurs. Et vu que le workflow de stream est ouvert, c'est beaucoup plus naturelle d'aller collaborer sur Stream pour Almalinux et co que de partir dans leur coin.
Je dit par design car le mot d'ordre de Centos, ça a toujours été "pour les changements, c'est bugzilla.redhat.com".
Ensuite, je comprends que pour la frange de la communauté qui veut des trucs gratos, ça semble faire chier. Mais c'est sans doute la même frange qui a du paniquer avec log4j partout.
Utiliser CentOS Stream est prod est un choix… A voir à long terme si tu as fais le bon, car le soucis n'est pas la migration mais le long terme avec ce changement.
Rappelons que CentOS Stream n'a rien à voir avec CentOS 8 (ou 9), par design on ne peut pas savoir à l'avance ce qui va casser.
on a pas réussi à trouver de quoi faire un article intéressant
Qu'avez-vous mis en place pour gérer les upgrades permanents de version de CentOS (c'est ce que c'est en pratique)? D'après ton commentaire ça a l'air d'être "rien", c'est être très joueur! Qu'est-ce qui a fait le choix d'être si joueur?
Qu'avez-vous mis en place pour gérer les upgrades permanents de
version de CentOS (c'est ce que c'est en pratique)? D'après ton
commentaire ça a l'air d'être "rien", c'est être très joueur!
Qu'est-ce qui a fait le choix d'être si joueur?
# Et toujours LA question
Posté par Jean Gabes (site web personnel) . Évalué à 3.
Switcher sur Rocky ou bien Alma? :D
[^] # Re: Et toujours LA question
Posté par Misc (site web personnel) . Évalué à 6.
Y a aussi Centos Stream.
Mon chef voulait qu'on fasse un article de blog sur notre expérience de la migration, mais vu que y a 2 commandes donné dans la FAQ et le reste marche pareil, on a pas réussi à trouver de quoi faire un article intéressant (genre, même pas "on a pu rajouter un correctif de bug" vu qu'on a pas eu de bugs).
Je vois vraiment pas trop pourquoi partir sur les dérivés qui vont avoir les mêmes paquets, mais avec au mieux, un délai dans les correctifs de bugs, au pire, un différentiel sans la majorité des devs pour s'en occuper.
[^] # Re: Et toujours LA question
Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 5.
Un article pour dire que tout s'est bien passé les doigts dans le nez ? C'est bien aussi.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Et toujours LA question
Posté par Psychofox (Mastodon) . Évalué à 5.
Tu veux dire que tu as migré vers l'un des sus-nommé ou vers Stream ?
Je serais intéressé d'un retour d'expérience d'une entreprise qui utilise une rolling release en prod, chaque fois que j'ai suggéré l'idée dans mes employeurs précédent j'ai assisté à une grande levée de boucliée mais sans réel argument pertinent. Il est facile de séparer OS de base et applis critiques , de faire pointer des environnements différents sur des snapshots différents des repos, d'automatiser des suites de tests.
[^] # Re: Et toujours LA question
Posté par Misc (site web personnel) . Évalué à 3.
Vers Stream
Alors vu mon employeur, le mandat de mon équipe et surtout la taille du parc et de l'équipe que je soit un bon exemple.
Mais je pense aussi qu'appeler Centos 8 une "rolling release", c'est comme dire qu'un avion est une automobile parce que ça peut se déplacer sur une route.
Centos 8 a des tests de QA automatisé, une promesse de compatibilité binaire via RHEL, et une politique de ne pas mettre à jour de façon disruptive. C'est ni Rawhide, ni Debian Unstable ou les devs vont mettre à jour sur la derniére version d'upstream, dont le but est de preparer la prochaine stable, etc.
Centos 8 stream est déjà stable (au sens figé), et la seule différence avec avant, c'est d'avoir les mises à jours de sécurité et de bugfix au fil de l'eau, donc de ne pas attendre que RHEL fasse une release, ce qui est pour moi un bonus.
Si un bug passe dans Centos Stream 8, le bug aurait fini par arriver dans la version stable mais plus tard, il y a pas de magie. Et vu que Centos n'a pas de support pour les versions mineurs autre que la dernière, tu es quand même obligé de mettre à jour pour la sécurité. Prendre une version mineur et appliquer les correctifs 1 par 1, c'est ni supporté, ni supportable, vu que tout est construit en visant les derniers RPMs. Ça marche sans doute plus parce que les paquets ont des modifs minimums plus que par un design particulier de la distro.
Ensuite, la ou je peux imaginer qu'une rolling release importen, c'est ce qui est hors de la distribution. Par exemple, le kernel ne garanti pas son ABI (même dans les LTS, etc), donc les gens qui dépendent de drivers externes ont sans doute peur de soucis (souci qui existe deja de base avec une mise à jour de sécurité avant, vu que l'ABI est toujours non garanti).
De même, Centos ne va tester que la distribution, si un produit proprio externe dépend d'un truc non documenté, ça peut casser. Mais pareil, ça aurait fini par casser à tout moment lors d'une mise à jour de sécurité.
Donc moi, j'ai ni l'un, ni l'autre, donc quand on m'a dit "tu vpeux avoir des bugfixes plus vite, et faire des PR plutot que d'aller faire chier les products managers/owners", j'ai dit "banco".
[^] # Re: Et toujours LA question
Posté par Psychofox (Mastodon) . Évalué à 5.
Centos Stream n'est pas Centos 8 Stream.
Sûr pour l'instant ça n'a pas trop dérivé mais l'idée derrière c'est qu'il n'y aura pas une centos 8 stream puis une centos 9 stream. C'est Centos stream rolling release. Ce qui veut dire que tôt ou tard ils vont introduire des trucs qui pète.
Prenons un exemple: la syntaxe des fichiers de configs des containers lxc a changé entre ubuntu 16.04 et ubuntu 18.04. Quand la 16.04 était sur le point d'arriver en fin de vie on a upgradé un certain nombre de machines, dont des hyperviseurs LXC et on a eu besoin de migrer ces fichiers de config. Sur une rolling release tu n'as pas cette délimitation de version, à un moment donné ton app doit passer de version majeur introduisant des changement. Tu as le choix:
- d'informer les utilisateurs du changement et espérer pour eux qu'ils lisent les news pour ne pas péter leur distro (j'avais par exemple pété une archlinux en faisant un pacman -Syu sans m'informer avant il y'a quelques années quand ils ont dépréciés la séparation /bin /usr/bin).
- d'avoir des scripts blindés qui prennent en charge tous les cas de figures. C'est parfois très difficile voire impossible.
Donc tôt ou tard ça arrivera sur Centos Stream. Je ne parles pas forcément de péter sa distro mais ça peut être simplement un changement d'une version majeure d'une application qui a déprécié depuis déjà n versions certaines syntaxes de ses fichiers de configuration et qui du jour au lendemain refuse de démarrer après une upgrade. Avec un parc correctement géré, des séparations d'environnements et des tests ad-hoc ce n'est pas la fin de monde, mais c'est une façon différente de gérer sa distro qu'avec le modèle de versions majeures dures qui aspirent à ne casser aucune compatibilité durant tout le cycle de vie.
[^] # Re: Et toujours LA question
Posté par Misc (site web personnel) . Évalué à 3.
En l'occurrence, il y a bien une différence entre Centos stream 8 et Centos Stream 9.
Le miroir a un répertoire 9-stream, pas "stream".
http://mirror.stream.centos.org/9-stream/
Ou "8-stream", pas "stream"
http://mirror.centos.org/centos/8-stream/
C'est aussi dans la FAQ:
"Around the time the RHEL 9 Public Beta is issued, an additional set of CentOS Stream repositories and ISOs will be available"
On ne le voit pas, mais j'ai surligné en flu "additional" sur mon écran :p
Donc quand le système passes de Centos 8 à Centos Stream 8, pas grand chose ne change, et il n'y a pas de migration magique vers Centos Stream 9 quand CS9 est dispo (la preuve, c'est dispo, et j'ai encore des CS8 en prod).
Et Centos Stream 8 est supporté jusqu'à la fin mai 2024, cf le site.
Ensuite, prendre Centos Stream 9 en production pour le moment (cad avant la release de RHEL final), c'est en effet autre chose. D’expérience, la bêta ne va pas avoir des changements énormes, et on a prévu d'en installer une sur un hyperviseur (parce que YOLO). Mais le matos vient juste d'être livré, donc je peux pas dire grand chose avant quelques semaines.
A titre perso, j'ai un pc qui me sert de serveur que j'ai installé avec une version beta de RHEL 7 (comme un goret en prenant la tour au bureau et en allant taper dans le miroir interne), et je me souviens pas avoir eu de souci notable à cause de ça, donc je ne pense pas que CS9 dans la phase avant la release de RHEL soit fondamentalement cassé.
Et si les gens pensent qu'il n'y a qu'un seul flux de la distro pour 8 et 9, je comprends mieux pourquoi tout le monde s'affole. J'imagine que le site web pourrait être plus clair à ce sujet.
[^] # Re: Et toujours LA question
Posté par Psychofox (Mastodon) . Évalué à 4. Dernière modification le 14 janvier 2022 à 16:17.
Ben c'est comme cela que ça avait été annoncé en fait. J'ai plus l'impression que c'est un rétropédalage pour ne pas perdre trop d'utilisateurs.
Merci pour les précisions.
[^] # Re: Et toujours LA question
Posté par Renault (site web personnel) . Évalué à 5. Dernière modification le 14 janvier 2022 à 16:46.
Bah… non ?
Par exemple la FAQ de CentOS en décembre 2020 (le mois de l'annonce du passage à CentOS Stream) : https://web.archive.org/web/20201221093230/https://centos.org/distro-faq/
La question 6 est assez explicite :
Notons que la page actuelle n'a rien changée du tout avec cette formulation (lire https://centos.org/distro-faq/). Donc il n'y a pas eu de changements, c'était plutôt clair.
Ou encore le blog de CentOS en décembre 2020 qui avait un diagramme plutôt clair. :
On voit clairement qu'il y a des branches par version majeure qui sont indépendantes entre elles.
Alors perso j'ai quelques critiques à faire sur leur annonce en terme de timing décisionnel, mais cet aspect a été je pense bien couvert dès le début. C'est difficile de faire plus clair ou de voir la confusion depuis les sources officielles (je ne parle pas des propos déformés sur d'autres sites).
Je trouve cela inquiétant si certains défendent CentOS Stream comme un ArchLinux à la sauce RHEL. Et surtout envisager de migrer sur Alma ou Rocky sans même avoir pris le temps de bien lire et réfléchir à ce qu'était CentOS Stream d'abord.
[^] # Re: Et toujours LA question
Posté par Misc (site web personnel) . Évalué à 4.
C'est dans la version 1 de la FAQ qui date de mars 2020.
C'est aussi dans la version de septembre 2020 sur archive.org, pour le cas ou il y a des doutes sur un éventuelle caviardage de l'historique du wiki.
Je rappelle aussi que l'annonce du changement de Centos 8 vers Stream date de décembre 2020, soit 9 mois après la première FAQ.
Donc à moins de supposer l'usage d'un ordinateur quantique pour voyager dans le temps (on a déjà la technologie pour dilater le temps par l'usage de slides en police taille 7, donc le reste est faisable) ou d'un complot qui implique tout le monde sauf les utilisateurs Centos, je pense pouvoir dire que c'est pas un retro pédalage.
[^] # Re: Et toujours LA question
Posté par Zenitram (site web personnel) . Évalué à 1.
Ben justement : non (d'après toi, pourquoi donc RH vend le support sur RHEL et on pas Stream?).
Vous avez donc décidé d'utiliser les "release candidate", la où des bugs (y compris des regrettions) sont chopés avant d'être en stable donc avec plus de bugs que RHEL (ou Rocky Linux), en prod sans vraiment l'assumer, on a l'impression…
[^] # Re: Et toujours LA question
Posté par Misc (site web personnel) . Évalué à 4.
Je note qu'on te reconnaît à ton audace.
Mais en effet, je peux te dire pourquoi le support de mon employeur est sur RHEL et pas sur Stream, et pourquoi y a des versions stables.
Primo, c'est pour les certifications, notamment en vue de vendre au gouvernement fédéral des USA (mais pas que). Si tu veux vendre à l'armée américaine, faut que ton produit soit certifié par le NIST. Je ne connais pas le détail, mais ç'est sans doute comme les processus de certifications ISO. C'est pas forcément compatible avec la façon de faire dans le logiciel libre, et il faut donc séparer les 2. Par exemple, j'imagine qu'il y a des questions d'audit, donc d'avoir un salarié RH responsable d'avoir pris le code de la communauté (eg, un truc d'ordre legal).
Moi, je m'en fout de FIPS, et je suppose toi aussi. Mais pas certains clients, donc si les clients veulent du FIPS, il y a du FIPS. En règle général, la communauté n'en veut pas, et ne va pas se plier aux règles de certifications.
Ensuite, parce qu'il faut traduire la documentation et les logiciels, car non seulement tout le monde ne parle pas anglais, mais en plus, il y a des pays ou tu peux pas vendre au gouvernement sans ça (exemple, la loi no 94-665 du 4 août 1994 relative à l'emploi de la langue française). La traduction, ça implique aussi d'avoir une période ou les chaînes ne bougent pas, et de sortir plus tard.
Moi, je m'en fout, je parle anglais, donc je préfère ne pas attendre. Mais quand un client demande ça, tu t'adaptes.
Tertio, parce que le marketing se sert des versions stables pour faire du marketing. Envoyer des mails, présenter les fonctionnalités, inviter les clients à regarder des photos de croissants pour rappeler ce qu'on avait avant la pandémie, tout ça.
Moi, je m'en fout un peu, j'ai une boulangerie en bas de chez moi. Et la communauté du libre en général semble ne pas trop faire de marketing.
Donc il y a tout un tas d'activité d'une boite normale qui s'appuie sur l'idée d'avoir une release, mis qui sont non seulement pas important pour la plupart des utilsiateurs finaux (eg, le marketing), mais qui vont aussi rajouter de la lenteur qui ne va pas bénéficier à grand monde (FIPS et divers certifications).
Ma foi, si tu vois un régression, n'hésite pas à montrer le bug tracker qu'on puisse en discuter sur la base des faits.
Sinon, tu es juste en train de faire du FUD a quelqu'un de visiblement mieux placé que toi sur le sujet.
Non, pour ça, j'ai des serveurs Fedora en prod, comme par exemple, une paire de firewall en HA:
$ ssh masa.rht.gluster.org -l root uname -aLinux masa.rht.gluster.org 5.14.14-300.fc35.x86_64 #1 SMP Wed Oct 20 16:14:50 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
Ou des reverses proxy en HA:
$ ssh proxy01.rht.gluster.org -l root uname -aLinux proxy01.rht.gluster.org 5.14.15-300.fc35.x86_64 #1 SMP Wed Oct 27 15:53:39 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
Mais je fait pareil avec mes serveurs perso sur mon lan:
$ ssh root@git.home uname -r5.15.12-200.fc35.x86_64
Ou hors du lan:
$ ssh root@xmpp uname -r5.14.17-301.fc35.x86_64
Et crois moi, j'ai aucun souci à mettre à jour ces machines vers les beta de Fedora, donc je pense que j'arrive pleinement à faire la différence entre une RC et une stable à l'usage.
Sinon, tu peux aussi aller dire à Facebook qu'ils n'assument pas, vu le slide 24.
[^] # Re: Et toujours LA question
Posté par Jean Gabes (site web personnel) . Évalué à 4.
Je ne dis pas que c'est une mauvaise distribution qui ne fonctionnera pas techniquement, mais le problème n'est pas technique justement.
C'est juste qu'il est impossible de dire "production" sur Centos Stream au client final (lui retient que c'est avant RedHat qui lui est stable/production), donc c'est forcément moins stable (peu importe la réalité de sa stabilité).
Tout n'est qu'une question d'image ici. Stream peux avoir toutes les qualités possibles, son image est:
* centos8 a été avorté en terme de support, donc manque de confiance envers RedHAt sur le sujet après pour ce qui concerne autre chose que RHEL, Stream en hérite automatiquement,
* c'est avant la RHEL/production dans son workflow, donc c'est instable/qualification. Basique.
Et c'est bien ce que souhaite RedHat je pense, qu'on arrête d'avoir une distribution "production" gratuite (qu'en plus lui paie ). C'est réussit :)
[^] # Re: Et toujours LA question
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
Stream n'est pas supposé être le bac à sable de RHEL ni être une Fedora Entreprise ; c'est ce que nous assure Red Hat. Après, dans son positionnement par rapport au produit final ça fait un peu la RC puisqu'on nous dit que ce n'est pas la ß…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Et toujours LA question
Posté par Renault (site web personnel) . Évalué à 3.
Dire que CentOS 8 Stream est la Beta de RHEL signifie que RHEL était la Beta de CentOS (sans Stream), ça n'a pas beaucoup de sens.
Le qualificatif de stable / pas stable, Beta / final n'a pas beaucoup de rapport avec l'ordre du workflow.
[^] # Re: Et toujours LA question
Posté par Zenitram (site web personnel) . Évalué à 2.
Pas du tout! Aucun lien.
RHEL était la version brandée RH de CentOS.
Rappelons que CentOS (et maintenant Rocky) sont des RHEL débrandée mais sinon identiques y compris les bugs.
Ben si, même RH le dit:
Fedora --> CentOS Stream --> RHEL, à chaque fois des modifs / stabilisations des logiciels.
RHEL --> CentOS, que debranding.
[^] # Re: Et toujours LA question
Posté par Renault (site web personnel) . Évalué à 4.
C'est pour moi assez trompeur de dire ça car en réalité il y a un délai (non négligeable) entre RHEL et CentOS avant.
Tu pouvais avoir un bogue dans RHEL, corrigé rapidement après et CentOS n'a pas eu la MaJ avec le bogue entre temps !
Pour moi ce raisonnement n'aurait réellement de sens que si la synchronicité entre RHEL et CentOS était de l'ordre de la journée, pas de plusieurs semaines (voire mois par moment selon les MaJ).
Du coup, si on suit le même raisonnement, à cause des délais, RHEL était la Beta de CentOS normal.
Je ne vois pas en quoi cela signifie que CentOS Stream n'est pas stable ou est une Beta de RHEL. Être l'amont n’implique pas cela.
[^] # Re: Et toujours LA question
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
C'est pour cela que je dis qu'il faut voir ça plus comme une RC (et avant, c'est RHEL qui l'était pour CentOS.) La grande inquiétude pour les usagers de Stream est que rien ne garanti que ce sera toujours la même chose à l'arrivée dans RHEL ni qu'un truc ne sera pas poussé prématurément pour tester avant les clients qui payent…) Let's wait and see.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Et toujours LA question
Posté par Misc (site web personnel) . Évalué à 2.
Sauf que c'est complètement con de pousser un truc "pour tester" si les gens ne savent pas qu'il y a un changement.
Le but d'un test, c'est d'avoir des retours, et pour avoir des retours, faut que les gens soient d'accord et bossent avec toi.
Personne ne va pousser un truc en se disant "yolo, ça va peut être casser la prod". Je rappelle aussi qu'il y a des tests automatisés, donc à minima, les fonctionnalités de base sont vérifiés.
Si le but est de faire des tests, le modèle d'EPEL et de Fedora avec un dépôt "testing" et des volontaires marchent largement mieux, donc pourquoi se faire chier à faire autrement vu que ça va juste apporter des emmerdes à tout le monde ?
D'ailleurs, c'est pour ça aussi qu'il y a des structures séparées, les SIG (exemple) pour justement permettre ce genre de choses. Et les SIGs ne datent pas de Stream, il y a déjà eu ça à l'époque de Centos 7.
Donc si ça ne bénéficie à personne, si il y a explicitement une structure ailleurs documenté pour faire les tests, pourquoi quelqu'un ferait le contraire ?
[^] # Re: Et toujours LA question
Posté par Misc (site web personnel) . Évalué à 5.
Image en partie poussé aussi par les concurents. J'ai vu assez de commerciaux pour savoir qu'ils ont aucun scrupule à ce niveau la.
Centos n'avait pas de support avant (au sens support téléphonique, tout comme au sens recevoir des bugs), donc au final, si le client découvre qu'il n'avait personne à appeler, ç'est tant mieux.
C'est un peu du bullshit comme raisonnement, vu que personne ne va mettre des Linux Mint en prod parce que c'est après Ubuntu qui est après Debian.
Si RH voulait se débarrasser de Centos, il suffisait d'attendre.
Tout les clones ont fini par s’arrêter d'eux même, et Centos elle même n'était super vivace vers 2011-2013, avec une gouvernance non transparente, etc.
Par exemple, il y a eu un délai de 6 à 7 mois entre RHEL et Centos pour les versions 6.0 et 6.1 (à comparer avec le mois pour Centos 5.0 et 5.1).
En pratique, je pense que ce que Centos a fait, c'est surtout décimer les distros concurrentes de RHEL. Vu que personne n'a les moyens d'attaquer RHEL par le haut en fournissant un produit plus prestigieux et de meilleur qualité, le seul moyen de concurrencer c'est en étant moins cher ou différent.
Sauf que faire moins cher que Centos, c’est quand même tendu.
Et faire différent, c'est pas évident non plus. Oracle a tenté, ils ont pas réussi.
Donc RH avait tout à gagner à garder Centos en vie.
Et RH a encore plus à gagner à avoir des clones actifs vu que les dits clones ont réussi à faire ce que Centos n'a jamais pu faire par design, à savoir rassembler une communauté de contributeurs. Et vu que le workflow de stream est ouvert, c'est beaucoup plus naturelle d'aller collaborer sur Stream pour Almalinux et co que de partir dans leur coin.
Je dit par design car le mot d'ordre de Centos, ça a toujours été "pour les changements, c'est bugzilla.redhat.com".
Ensuite, je comprends que pour la frange de la communauté qui veut des trucs gratos, ça semble faire chier. Mais c'est sans doute la même frange qui a du paniquer avec log4j partout.
[^] # Re: Et toujours LA question
Posté par Zenitram (site web personnel) . Évalué à 4. Dernière modification le 14 janvier 2022 à 12:48.
Utiliser CentOS Stream est prod est un choix… A voir à long terme si tu as fais le bon, car le soucis n'est pas la migration mais le long terme avec ce changement.
Rappelons que CentOS Stream n'a rien à voir avec CentOS 8 (ou 9), par design on ne peut pas savoir à l'avance ce qui va casser.
Qu'avez-vous mis en place pour gérer les upgrades permanents de version de CentOS (c'est ce que c'est en pratique)? D'après ton commentaire ça a l'air d'être "rien", c'est être très joueur! Qu'est-ce qui a fait le choix d'être si joueur?
[^] # Re: Et toujours LA question
Posté par Misc (site web personnel) . Évalué à 2.
On a rien mis de plus, on sait lire une FAQ.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.