> Le fait que cela soit repandu ou standard ne prejuge en rien de sa qualite.
>
> Je suis rassure que les gens de Ielo aient ecarte libvirt, ca montre qu'ils savent voir au dela du hype.
Le fait que les gens de lelo aient écarté libvirt, ne préjuge en rien qu'ils savent faire les bons choix.
Ils font bien dans le "hype", la virtualisation est "hype". Dans ce "hype", ils ont pris ce qu'il y a de plus "hype" : kvm.
> C'etait une piece importante de la strategie de RH et lui a permis de changer de solution de virtualisation sous-jacente (de xen a kvm).
Oui, mais pas seulement. Quand libvirt a été fait, personne ne savait qu'il y allait avoir kvm. Le pire ici n'est pas libvirt, mais xend qui a voulu tout faire à la fois en étant lié à une seule techno... Kvm est un remplaçant de Xen. Mais il y autres solutions de virtuailisation qui ne sont pas des remplaçants de Xen et ont leur place. Par exemple les conteneurs. Ce n'est pas actuellement la priorité de Red Hat, mais ces derniers ne sont morts. Un datacenter pourrait combiner OpenVZ et KVM.
> Mais cela reste amha une usine a gaz fragile qui n'exploite que le plus petit commun denominateur. Un design clean a partir de zero pour un produit qui ne tente pas d'utiliser plusieurs hyperviseurs ne me parait pas idiot.
Faire Xend, Kvmd, OpenVZd, etc...
Pas sûr que ça donne plus de qualité.
Quelques soit le système de virtualisation il y a des points communs. Le stockage, l'installation, la migration (à chaud ou froid), l'affichage, la sécurité/authentification, etc.
> remarquer qu'il y a des outils simples fait par des admins pour des admins qui marchent bien (genre kvmctl
Qui ne gère pas l'accès à distance, la création de vm, etc, etc.
> Cela dit, comme le nom de leur groupe l'indique, ce sont surtout des gens qui font des prototypes qui passent ensuite souvent en prod tels quels
Faut bien faire des prototypes. et.redhat.com n'est pas un groupe spécifique de personne qui ne font que ça.
Il y a des développeurs de libvirt, func, etc. L'idée est qu'il y a des solutions qui ont plus de sens lorsqu'elles sont couplées avec d'autres. L'idée est aussi de donnée plus de lumière à des solutions qui semblent prometteuses selon Red Hat.
> Ce faisant, ils ont tendance a privilegier le quick and dirty et non un design propre/sain.
Le kvmctl que tu donnais était du quick and dirty. Et ça ne voulait pas être plus.
> [une pile de reproche plus ou moins valable]
> Alors, oui, ils contribuent, mais leurs choix ne sont pas forcement les meilleurs.
Ils l'ont fait. Au premier jet rien est parfait et un programme est toujours en développement.
> D'autre part, ils n'ont pas la main-mise sur qemu (ils n'ont meme pas d'acces en ecriture au repo pour l'instant) donc rien n'empeche les gens de Ielo/LO ou des contributeurs externes de rajouter des fonctionnalites.
Oui, et c'est très bien. Je ne vois pas problème ici, au contraire.
[^] # Re: Libvirt ?
Posté par IsNotGood . En réponse à la dépêche Première publication de la plate-forme libre de HaaS (Hardware as a service) NiftyName. Évalué à 2.
>
> Je suis rassure que les gens de Ielo aient ecarte libvirt, ca montre qu'ils savent voir au dela du hype.
Le fait que les gens de lelo aient écarté libvirt, ne préjuge en rien qu'ils savent faire les bons choix.
Ils font bien dans le "hype", la virtualisation est "hype". Dans ce "hype", ils ont pris ce qu'il y a de plus "hype" : kvm.
> C'etait une piece importante de la strategie de RH et lui a permis de changer de solution de virtualisation sous-jacente (de xen a kvm).
Oui, mais pas seulement. Quand libvirt a été fait, personne ne savait qu'il y allait avoir kvm. Le pire ici n'est pas libvirt, mais xend qui a voulu tout faire à la fois en étant lié à une seule techno... Kvm est un remplaçant de Xen. Mais il y autres solutions de virtuailisation qui ne sont pas des remplaçants de Xen et ont leur place. Par exemple les conteneurs. Ce n'est pas actuellement la priorité de Red Hat, mais ces derniers ne sont morts. Un datacenter pourrait combiner OpenVZ et KVM.
> Mais cela reste amha une usine a gaz fragile qui n'exploite que le plus petit commun denominateur. Un design clean a partir de zero pour un produit qui ne tente pas d'utiliser plusieurs hyperviseurs ne me parait pas idiot.
Faire Xend, Kvmd, OpenVZd, etc...
Pas sûr que ça donne plus de qualité.
Quelques soit le système de virtualisation il y a des points communs. Le stockage, l'installation, la migration (à chaud ou froid), l'affichage, la sécurité/authentification, etc.
> remarquer qu'il y a des outils simples fait par des admins pour des admins qui marchent bien (genre kvmctl
Qui ne gère pas l'accès à distance, la création de vm, etc, etc.
> Cela dit, comme le nom de leur groupe l'indique, ce sont surtout des gens qui font des prototypes qui passent ensuite souvent en prod tels quels
Faut bien faire des prototypes. et.redhat.com n'est pas un groupe spécifique de personne qui ne font que ça.
Il y a des développeurs de libvirt, func, etc. L'idée est qu'il y a des solutions qui ont plus de sens lorsqu'elles sont couplées avec d'autres. L'idée est aussi de donnée plus de lumière à des solutions qui semblent prometteuses selon Red Hat.
> Ce faisant, ils ont tendance a privilegier le quick and dirty et non un design propre/sain.
Le kvmctl que tu donnais était du quick and dirty. Et ça ne voulait pas être plus.
> [une pile de reproche plus ou moins valable]
> Alors, oui, ils contribuent, mais leurs choix ne sont pas forcement les meilleurs.
Ils l'ont fait. Au premier jet rien est parfait et un programme est toujours en développement.
> D'autre part, ils n'ont pas la main-mise sur qemu (ils n'ont meme pas d'acces en ecriture au repo pour l'instant) donc rien n'empeche les gens de Ielo/LO ou des contributeurs externes de rajouter des fonctionnalites.
Oui, et c'est très bien. Je ne vois pas problème ici, au contraire.