While many Red Hat open-source projects end up being relatively instant successes that then end up being widely adopted in the open-source community, Red Hat's Stratis Storage effort seems to be trending as one of the exceptions. Red Hat continues investing in Stratis but it doesn't seem to have the sizable adoption or widespread interest that tends to come with most of their projects.
Je suis pas sur ceci dit qu'il y a grand chose à adopter.
C'est dispo dans RHEL 9 comme tech preview, et au delà de ça, je sais pas trop ce qu'il faut de plus.
RHV est en train de bouger pour se baser sur Openshift et kubevirt plutot que le moteur d'Ovirt (et que je sache, personne ne se bouscule pour reprendre le projet) et ça utilise ceph et rook pour la gestion du stockage sur un cluster, donc je doute que stratis soit utile à ce niveau.
Les autres produits ne touchent pas trop au stockage. Tout au plus, un composant qui pourrait avoir un support de statis serait cockpit, mais ça va sans doute arriver une fois que stratis n'est plus en tech preview. Et j'imagine qu'il y a peut être des choses à faire du coté de gnome, mais il faudrait que stratis soit suffisamment utilisé pour que ça vaille le coût.
Le stockage, c'est comme le logement des chiens, ça reste un sujet de niche.
C'est dispo dans RHEL 9 comme tech preview, et au delà de ça, je sais pas trop ce qu'il faut de plus.
C'était déjà en tech preview dans RHEL 8, le status n'avance pas, ça ne va pas pousser à l'adoption.
t ça utilise ceph et rook pour la gestion du stockage sur un cluster,
Peut-être qu'il y aurait des avantages pour rook pour faciler l'extension. Mais bon, pas sûr. Peut-être que les noeuds openshift pourrait l'utiliser pour pouvoir gérer plus facilement le stockage local. Mais effectivement, ce ne serait pas une révolution.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
C'était déjà en tech preview dans RHEL 8, le status n'avance
pas, ça ne va pas pousser à l'adoption.
en effet.
Je pense que le choix de Fedora de prendre Btrfs n'a pas du aider.
Ensuite, quelque chose peut passer de TP à "support complet" lors d'une version mineure de RHEL.
Et sauf erreur de ma part, le fait de choisir si quelque chose est en TP, c'est aussi sur des critères comme la stabilité assez absolu de l'API et le fait que le support soit formé pour répondre aux questions, donc ça ne reflète pas forcément la maturité pour l'adoption plus que l'adéquation avec une offre de support longue durée (eg, 10 ans).
Les arguments en faveur de XFS (et donc stratis) avait été assez bien expliqué par le chef de l'équipe storage d'il y a 5 ans:
- un filesystem, c'est long à stabiliser (en tout cas, au niveau ou on veut pas avoir à appeler un client pour lui dire "vous avez bien des backups")
- RH a investit sur XFS (embauche d'ancien de SGI, etc) et LVM (rachat de sistina) et connaît ces technos
- les clients demandent btrfs, mais pas pour le FS en lui même, mais pour les features et l'UX
Donc la solution est de garder la stack actuelle qui a fait ses preuves (lvm+xfs) et de rajouter par dessus un UX, en l'occurence, stratis.
Ensuite, je suis d'accord que c'est pas forcément le pari gagnant d'un point de vue de l'adoption.
Suse et Oracle ont misé sur btrfs (et c'était en TP dans RHEL 6 et 7), Facebook a visiblement aussi beaucoup investi. La communauté Fedora a poussé btrfs en partie pour s'aligner avec Suse et je pense en partie parce que btrfs était la et pas Stratis.
Ensuite, stratis semble plus compliqué à supporter dans une distro que btrfs. Pour btrfs, tu rajoutes le support dans le kernel, dans l'initrd et dans l'installeur. C'est assez standard vu que c'est rajouter des modules, et sans doute quelques trucs classique dans l'installeur (eg, lancer mkfs.XXX et copier des binaires).
Pour stratis, j'ai l'impression que c'est plus comme rajouter le support de lvm. Tu va devoir mettre un peu plus qu'un module noyau vu qu'il faut peut être lancer le demon dans l'initrd, etc.
# Discussion
Posté par antistress (site web personnel) . Évalué à 4.
Que pensez-vous de :
?
[^] # Re: Discussion
Posté par claudex . Évalué à 4.
Ben, j'ai l'impression que même redhat ne l'adopte pas plus que ça.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Discussion
Posté par Misc (site web personnel) . Évalué à 3.
Je suis pas sur ceci dit qu'il y a grand chose à adopter.
C'est dispo dans RHEL 9 comme tech preview, et au delà de ça, je sais pas trop ce qu'il faut de plus.
RHV est en train de bouger pour se baser sur Openshift et kubevirt plutot que le moteur d'Ovirt (et que je sache, personne ne se bouscule pour reprendre le projet) et ça utilise ceph et rook pour la gestion du stockage sur un cluster, donc je doute que stratis soit utile à ce niveau.
Les autres produits ne touchent pas trop au stockage. Tout au plus, un composant qui pourrait avoir un support de statis serait cockpit, mais ça va sans doute arriver une fois que stratis n'est plus en tech preview. Et j'imagine qu'il y a peut être des choses à faire du coté de gnome, mais il faudrait que stratis soit suffisamment utilisé pour que ça vaille le coût.
Le stockage, c'est comme le logement des chiens, ça reste un sujet de niche.
[^] # Re: Discussion
Posté par claudex . Évalué à 4.
C'était déjà en tech preview dans RHEL 8, le status n'avance pas, ça ne va pas pousser à l'adoption.
Peut-être qu'il y aurait des avantages pour rook pour faciler l'extension. Mais bon, pas sûr. Peut-être que les noeuds openshift pourrait l'utiliser pour pouvoir gérer plus facilement le stockage local. Mais effectivement, ce ne serait pas une révolution.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Discussion
Posté par Misc (site web personnel) . Évalué à 4.
en effet.
Je pense que le choix de Fedora de prendre Btrfs n'a pas du aider.
Ensuite, quelque chose peut passer de TP à "support complet" lors d'une version mineure de RHEL.
Et sauf erreur de ma part, le fait de choisir si quelque chose est en TP, c'est aussi sur des critères comme la stabilité assez absolu de l'API et le fait que le support soit formé pour répondre aux questions, donc ça ne reflète pas forcément la maturité pour l'adoption plus que l'adéquation avec une offre de support longue durée (eg, 10 ans).
Les arguments en faveur de XFS (et donc stratis) avait été assez bien expliqué par le chef de l'équipe storage d'il y a 5 ans:
- un filesystem, c'est long à stabiliser (en tout cas, au niveau ou on veut pas avoir à appeler un client pour lui dire "vous avez bien des backups")
- RH a investit sur XFS (embauche d'ancien de SGI, etc) et LVM (rachat de sistina) et connaît ces technos
- les clients demandent btrfs, mais pas pour le FS en lui même, mais pour les features et l'UX
Donc la solution est de garder la stack actuelle qui a fait ses preuves (lvm+xfs) et de rajouter par dessus un UX, en l'occurence, stratis.
Ensuite, je suis d'accord que c'est pas forcément le pari gagnant d'un point de vue de l'adoption.
Suse et Oracle ont misé sur btrfs (et c'était en TP dans RHEL 6 et 7), Facebook a visiblement aussi beaucoup investi. La communauté Fedora a poussé btrfs en partie pour s'aligner avec Suse et je pense en partie parce que btrfs était la et pas Stratis.
Ensuite, stratis semble plus compliqué à supporter dans une distro que btrfs. Pour btrfs, tu rajoutes le support dans le kernel, dans l'initrd et dans l'installeur. C'est assez standard vu que c'est rajouter des modules, et sans doute quelques trucs classique dans l'installeur (eg, lancer mkfs.XXX et copier des binaires).
Pour stratis, j'ai l'impression que c'est plus comme rajouter le support de lvm. Tu va devoir mettre un peu plus qu'un module noyau vu qu'il faut peut être lancer le demon dans l'initrd, etc.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.