C'est d'abord une culture. Quand on est en DevOps, on prend tout le monde.
DevOps et agile font effectivement partie de la même famille.
Sa virtualisation applicative, c'est très bien.
Aujourd'hui, ça nous prend 10 minutes et un café.
Ce n'est ni être dev, ni être DevOps. C'est avant tout de la communication.
Ce mouvement DevOps, c'est tout simplement drivé par la communauté
et endorsé par les entreprises.
J'ai adopté une démarche DevOps.
Le développement agile, on a accéléré des poignements.
Ça amène une clarté sur le travail de...
Être dans une démarche d'amélioration contiere au trou face à des...
Ça, oui, naturellement ensemble, ça donne des résultats contrêts.
DevOps.
L'objectif individuel, ça s'atteint alors qu'une ambition, ça se partage.
Bonjour à toutes et à toutes et bienvenue dans un nouveau numéro de DevOps.
Ça fait longtemps qu'on n'en a pas fait. J'ai l'impression de dire ça à chaque podcast.
Mais là, ça fait quand même un petit moment.
Et aujourd'hui, on va parler d'un vieux sujet, OpenStack.
Vieux sujet parce que c'est un logiciel qui n'est pas très récent pour le coup.
Mais ça fait un petit moment qu'on voulait en parler.
C'est un moment que le sujet peut revenir, surtout quand on le compare avec de la technologie actuelle.
Et donc avec moi aujourd'hui, j'ai plusieurs personnes qui vont se présenter via leur expérience.
Hello.
Alors, moi, c'est Flint. Vous pouvez me retrouver sur YouTube, sur Twitter.
Pardon. Sur Kobayashi Maru.
Mon boulot, c'est être senior architecte cloud privé, cloud public
pour une boîte qui fait de l'armement et d'identité.
Avant ça, j'ai fait pas mal de banques, d'hyper-scaleurs et de jeux vidéo.
Puis je me suis retrouvé à bosser là-dedans, maintenant, depuis 2012, on va dire.
Donc je vois sur OpenStack depuis 2012 avec pas mal de sujets autour de ça.
Sur comment est-ce qu'on déploie, comment est-ce qu'on le manage,
comment est-ce qu'on va gérer le lifecycle, qu'est-ce qui est contenu dans OpenStack,
qu'est-ce que ça fait, comment ça fonctionne, qu'est-ce qui fonctionne,
qu'est-ce qui fonctionne pas ?
Et toutes les questions, en fait, satélites à OpenStack, comme le storage,
cf, Kubernetes, les pratiques qui vont au-dessus,
comment est-ce qu'on emborde les gens, etc.
Voilà.
Hello tout le monde. Moi, c'est Julien.
Je suis ingénieur réseau SRE chez Dizer.
Je suis également IT et infrastructure manager pour les restos du cœur en tant que bénévole,
les restos du cœur de Réloir puisque je suis chartre.
Je suis aussi également DJ à mes heures perdues.
Ça m'arrive de mixer en festival principalement et puis aussi à côté de ça,
avant de bosser chez Dizer, j'ai bossé chez Rodeur,
une boîte qui fabrique un logiciel open source du MAPDAN
pour la gestion de configuration et fait de l'OpenStack maintenant depuis deux ans.
C'est quelque chose que je suis en train de mettre en place et mettre en disposition au niveau des restos du cœur
pour au-pris de l'infrastructure à toutes les antennes départementales
puisque les restos, c'est un peu éclaté sur toute la France
et pour au-pris, une infrastructure relativement solide à base d'OpenStack.
D'ailleurs, Rodeur, à mon avis, tout le monde doit les connaître si jamais on va dans une conférence
puisqu'ils sont quand même très souvent partenaires de conférence.
Et notamment, c'était dans le temps des DevOpsRex, etc.
J'étais même organisateur.
J'étais même organisateur tout à fait pour le DevOpsRex.
T'étais avec Dota Series Go LOD quand je bossais chez Rodeur,
même si le DevOpsRex était terminé, j'avais quand même la boîte Mail DevOpsRex
qui était fait automatiquement pour la Stats Series Go LOD.
C'est vraiment très cool.
On repasse le bonjour.
Ils ont été très importants et ils sont toujours très importants sur la CNFR dessus.
C'est vraiment très sympa.
Aujourd'hui, comme je l'ai dit en introduction, on va parler d'OpenStack.
Je vais me présenter un peu sur mon expérience avec OpenStack.
Je l'ai connu parce que je travaillais chez Claude Watt.
Claude Watt, on avait un OpenStack pour le coup, full public.
D'ailleurs, il y a des gens aussi, on est en direct sur Discord.
Il y a des gens aussi là qui nous écoutent, qui étaient avec moi chez Claude Watt.
On a beaucoup utilisé OpenStack, beaucoup fait de contribution d'ailleurs à Open Source.
Et c'est même via ce mode là, que je suis rentré vraiment dans le cloud public
et dans la création de ces clouds là.
C'est vrai que le fait que ce logiciel soit mal aimé,
je n'ai vraiment jamais trop compris pourquoi.
C'est un logiciel qui peut être très complexe, notamment quand on fait du cloud public avec,
quand on l'offre à disposition des autres.
Mais c'est aussi un cloud privé.
Et justement, je voulais savoir, est-ce que l'un de vous pouvait un peu me le décrire avec des mots,
savoir un peu comment lui expliquerait OpenStack.
Oui, complètement.
En fait, OpenStack, c'est, comme on le disait en introduction,
c'est un logiciel en fait qui est une collection de logiciels.
Donc déjà, ça c'est le premier truc à prendre en compte.
C'est que ce n'est pas un seul logiciel.
On parle d'OpenStack, mais OpenStack, c'est une suite de projet en fait.
Et le but de cette suite de projet, c'est tout simplement d'être ce qui est du leur de ressources.
Alors il y a des définitions à l'ambiqué qui vont être cloud, ressources manager, etc.
Je pense qu'elles sont trop justement à l'ambiqué et que ça perd un peu les gens.
Globalement, le but premier d'OpenStack, c'est d'être une abstraction aux ressources en fait
qu'on peut avoir dans une infrastructure, qu'elles soient dans un data center,
une salle technique, sous le bureau, etc.
Et en fait, ça permet quelque part de réunir toutes ces infrastructures un peu diverses et parces
au sein d'une seule et même interface unifiée, que ce soit des API ou le dashboard ou la CLI.
Donc grosso modo, n'importe quelle ressource, on peut manager de la VM, du conteneur,
des volumes de stockage, object storage ou block storage, mais aussi également des services
qui sont un peu plus abstrés par rapport au hardware qui vont être par exemple le DNS à the service,
l'authentification à the service ou les choses comme ça.
Et là, je me fais un peu l'avocat diable, mais c'est quoi la différence avec un Kubernetes pour le coup ?
Exactement. Alors la particular différence qu'on constate, on va dire, avec le Kubernetes,
c'est notamment justement sur les briques logiciels qui sont un peu plus proches du hardware.
Donc on va dire par exemple pour la gestion des VM, jusqu'à très récemment avec Kubird,
c'était un peu compliqué de spawner des VM.
C'était pas infaisable, mais c'était un peu plus compliqué.
Là, sur OpenStack, on a quand même quelque chose qui est rodé depuis longtemps.
T'as des services par exemple comme l'authentification type Keystone, qui eux vont être super efficaces
parce que t'as pas besoin de réinventer la roue, le service est là.
C'est-à-dire que si tu veux de l'authentification, c'est built-in.
T'as pas besoin d'aller chercher à refaire, en fait, refabriquer quelque chose de ton côté, c'est fourni par défaut.
Donc là justement, si on résume un peu les services qu'on a,
ça correspond à quoi à peu près les noms, la myriade de projet justement qu'on va avoir ?
Alors, il faut savoir un truc, c'est que sur OpenStack, t'as la notion en fait de ce qu'on appelle la BigTent.
Alors c'est une notion qui tend à disparaître parce que le nombre de projets augmentant,
ça va être difficile de tout garder sous la BigTent et ça va être difficile de garder Stalingrugilla.
Mais grosso modo, on rappelait ce qu'on appelle un OpenStack Vanilla.
C'est un OpenStack avec les services minimum, c'est-à-dire Keystone,
donc qui va être le service d'identification et d'authentification.
On va avoir Glence, qui est le service des images, donc de gestion des images au sens image de VM
ou container ou artefact en fait de déploiement pour la workload.
Tu as Cinder, qui est le service en charge de la gestion du BlockStorage.
T'as Swift, qui est en charge de la gestion de l'ObjectStore.
Tu as derrière Neutron, qui est en fait le service qui lui gère toute la partie réseau
et qui est en fait quasiment l'épidemursale d'OpenStack finalement,
parce que sans réseau, point de communication.
Et puis derrière normalement, tu as Horizon qui est en fait le dashboard
et qui se sert de tous les services précédemment cités pour offrir quelque part
une interface un peu cliquetique-clique à l'utilisateur.
Et donc chaque service qu'on vient de citer, il vient avec son endpoint API
qui te permet de l'instrumenter directement depuis un API.
Et c'est ce qui fait la force de tout ça, c'est qu'en fait quelque part derrière,
tu peux jouer au chef d'orchestre assez facilement avec tes ressources
puisque une fois qu'elles ont été adoptées par ces services-là,
tu peux directement les skéduller et les manager depuis ces services.
D'accord. Et donc là, tous ces services sont obligatoires et sont mandatorie.
Là, on est dans le bar minimum d'un OpenStack où c'est moduléable.
Alors jusqu'à il y a quelques temps, tu avais des attachements forts entre les services
et donc ces services-là, entre guillemets, ont recommandé de les installer toujours
avec le même package, c'est-à-dire toujours ce package-là de services
parce que ça faisait donc le corps vanillal.
Aujourd'hui, c'est moins vrai.
Tu pourrais en fait les installer un à un et utiliser un seul des services
parce que tu n'as besoin que de ce service-là, par exemple.
Tu pourrais dire, moi, j'ai un besoin de gestion de BlockStorage uniquement
et d'installer que Cinder.
Dans la majorité des cas, on installe le corps complet
pour la bonne et simple raison, c'est qu'on n'a jamais trop besoin
que d'un seul service et qu'à un moment donné,
bon, quand on fait de l'infrastructure à la demande,
généralement, on va essayer d'avoir un seul tool qui le fait
et du coup, on va déployer ces vanillalats.
Au-delà de ces services-cors,
tu as toute une autre ribambelle de projet qui existe
et qui eux sont totalement optionnels
puisque le principe même d'OpenStack, c'est de dire,
OK, chaque projet est censé être standalone et autonome,
mais être entreguimé et normalisé d'une façon
qui fait que chaque service, s'il a envie de parler avec les autres services d'OpenStack
et sous couvert de configuration correcte,
il va pouvoir et on va constituer en fait un catalogue de services
qui va permettre d'être accessible de façon unifiée
et qui va pouvoir s'appeler les uns les autres.
Et donc là, ça fait quand même, enfin, on peut dire,
ça fait quand même un peu de logiciel à installer tout ça.
Ça va être quoi les dépendances là, par exemple, Julien,
dans le cadre de ton install ?
C'est quoi à peu près les pré-requis que vous avez ?
Qu'est-ce que vous allez devoir installer ?
Parce que, enfin, je n'arrive pas à m'en rendre compte,
là, en tout cas, si j'écoute l'installation de tout ça,
à quel point ça correspond à une maintenance et un déploiement compliqué.
Le déploiement, on ne peut pas vraiment dire qu'il est compliqué,
puisque justement, tout l'environnement fait OpenStack fournit un outil,
donc Colin Siebel, il vient pour simplifier considérablement,
on va dire, le déploiement d'OpenStack,
afin de se foutre de certaines briques.
Nous, par exemple, au reste du cœur, on ne va pas embarquer tout,
on va vraiment avoir comme l'a dit, justement,
juste avant que certaines briques, les briques de base,
donc avec Colin, ça se fait très bien, très facilement.
Un gros avantage aussi que moi, j'y ai obligé,
en tout cas, pour l'utiliser maintenant au quotidien,
c'est que sur certains drivers, certains logiciels
qui sont proposés par OpenStack pour ajouter une certaine couche d'attraction,
c'est qu'on peut même les plugger automatiquement,
à des outils qui, eux, sont qu'on utilisait auparavant.
Par exemple, je vois, par exemple, pour la partie DNS,
des power DNS plutôt bind qui est fondi par défaut, par désignate,
et en fait, c'est tout à fait connecté sans aucun souci.
Et pour la partie load balancing, on est plutôt sur each proxy,
notre côté, et ça marche aussi très, très bien.
Donc, c'est aussi ça qui est important de souligner dans OpenStack,
c'est qu'on peut prévacilement abstraire l'infrastructure aussi actuelle,
on peut, c'est pas parce que vous avez des logiciels qui font, comment dire,
pas notés dans les standards, entre guillemets d'OpenStack,
qui ne sont pas forcément supportés.
Si vous regardez un petit peu les drivers, très souvent,
vous pouvez les différentes applications.
Oui, il y a cette notion que tu viens de donner, Junien,
qui est ultra importante effectivement sous OpenStack,
c'est que OpenStack, qui est le nom global du projet,
est une collection de projets, justement,
et chaque projet, en fait, pour pouvoir maximiser
les ressources qu'il va pouvoir gérer,
a en fait, en son sein, une mécanisme,
enfin, un mécanisme, pardon, de driver.
Donc, typiquement, si on prend l'object storage,
l'object storage, donc, Sinder, va pouvoir être capable
de s'attacher soit à des Bessanes à l'ancienne,
soit à du software define storage, type Cephe,
soit à d'autres types de storage,
enfin, de fournisseurs de stockage,
et globalement, la liste est plutôt longue.
Et donc, du coup, en fait, c'est intéressant parce que
ça permet réellement d'abstrait, à un niveau beaucoup plus élevé,
l'intégralité du stockage que peut avoir une entreprise
ou un groupe de personnes.
Donc, typiquement, tu peux, dans Sinder, choisir donc ton back-end de stockage,
mais tu peux, évidemment, avoir plusieurs back-ends de stockage en même temps,
parce qu'il suffit de lui dire,
OK, moi, je veux embarquer des zones Cephe,
des zones, je ne sais pas, moi, Itachi, des zones EMC2, etc.
Et en fait, ça va te permettre de couvrir l'intégralité
et de piloter surtout l'intégralité de tes ressources Block Storage comme ça.
Et donc, Sinder pour le Block Storage,
mais tu as également la même mécanique de driver pour Nova,
qui va gérer donc le compute.
Par défaut, effectivement, 90% des gens vont utiliser le KVM,
parce qu'on part avec du Linux, on part avec du KVM,
mais rien ne t'empêche d'utiliser un driver VMware,
un driver Hyper-V, un driver Xen.
Et donc, du coup, de driver depuis ton Nova,
tes ressources computes, qui elles se trouvraient sur des host
et qui se trouvraient en fait dans des régions gérées par ces outils-là.
Il est aussi important, en parlant de driver,
il est d'ailleurs aussi important de souligner que de troncs,
donc le driver SDN, software defined network,
d'open stack, et clairement, en fait, l'un des plus avancés
en termes de gestion réseau par rapport à ce qu'on peut prouver
sur des solutions beaucoup plus simplifiées,
mais par exemple, ça prend smoke via l'environnement,
qui est fourni un outil qui est un hyper-visor,
mais que maintenant, certains voient comme un mini-cloud privé.
La partie SDN est encore en beta, donc voilà, un petit peu...
Il y a d'autres solutions, il suffit de regarder Cloud Stack
de la condition Apache, ou c'est pareil,
la partie réseau est clairement pas aussi avancée
que ce qu'on va avoir côté open stack.
En fait, il y a quand même une certaine maturité,
il n'y a pas pour d'autres projets,
ça va être du même genre.
Pour dire, la partie réseau,
c'est fait aussi de la maturité dans la douleur,
pour avoir un outil open stack,
il y a un moment, ça a pu se faire un moment donné
dans la douleur, on va dire, cette partie...
La partie nouvelle network a été seulement dégueulasse,
mais clairement, il faut dire des termes...
Donc oui, c'est vrai.
Alors là, c'est marrant, t'as parlé justement
de Proxmox ou Proxmox pour les intimes.
Justement, ça va être...
Enfin, j'arrive pas à savoir encore
quel est le coût d'installation de tout ça.
Donc là, j'ai compris qu'il y avait de l'ancible
pour l'installer, etc.
Mais en termes de ressources, c'est gros,
qu'elles vont être mes dépendants, je sais pas.
Je peux obligé d'installer un Kafka,
je suis obligé d'installer des logiciels,
un ZooKeeper ou n'importe quoi,
parce qu'on sait qu'il y a plein de logiciels
qui ont besoin de ce genre de dépendance.
Là aujourd'hui, ça va être quoi la dépendance
que j'ai besoin de gérer moi en infra.
Si jamais je veux juste installer le bar minimum
d'avoir ça dans mon infra,
on parle pour l'instant bien sûr
de call privé, c'est-à-dire pour un usage interne.
Globalement, tout dépendra, je pense,
de ton besoin.
Forcément, ils souhaitent
déployer principalement, massivement,
des noeuds KVM pour fournir du compute.
Bien forcément que tes besoins ne sont pas les mêmes
que s'ils puissent chercher à fournir
en fait de la base de données
ou par exemple du RADIS,
un service ou genre de choses.
Tout dépendant, en fait, forcément,
de ce que tu souhaites, toi mettre en place derrière.
Je vais avoir la possibilité d'avoir du RADIS
à ce service si jamais je commence à me lancer
dans une instance OpenStack.
Alors pas au démarrage,
mais il y a effectivement un driver qui est fourni
Zakhar qui permet justement
de faire du RADIS Storage
à ce service.
On arrive vraiment à la notion de cloud,
pas d'hyper-scaleur parce qu'on n'est pas l'un de dans,
mais d'avoir des services manager
que je vais pouvoir retrouver au sein d'une équipe
qui va les fournir après aux autres
avec un service driver.
Et c'est ce qui est hyper intéressant
avec OpenStack, c'est que finalement
les services, habituellement
en côté infrastructure,
on va avoir des spécialités, donc quelqu'un
qui va plutôt spécialiser un RADIS Storage,
Compute, la partie networking,
et en fait le gros avantage
d'OpenStack avec tous ces modules,
c'est la driver, c'est que
ces drivers vont finalement concerner
que certaines personnes dans l'équipe
et ces personnes-là vont pouvoir rendre
en fait les anciens blocs
de l'infrastructure typiquement
des RADIS en tant que service
directement dans la plateforme OpenStack.
Je pense qu'il y a une analogie
qui marche très bien avec OpenStack,
c'est une analogie des Legos,
ou en fait
c'est vraiment une caisse de Lego
où tu vas avoir
les quatre barres,
double quatre barres jaunes,
deux rouges, etc.
En fait chaque service est une brique de Lego
que tu assembles et que tu peux
moduler comme tu veux.
Donc pour répondre à ta question, le barre minimum
si tu veux lancer un OpenStack
pour faire par exemple
du POC, c'est un serveur.
Tu peux faire un All-in-One, ça va te coûter
un serveur, alors faut que ça soit un peu pêchu
quand même parce que vu le nombre de services
que tu vas faire tourner dessus, faut que
ça puisse un peu envoyer, mais
globalement tu prends un serveur
32 coeurs, 64 gigadrammes, ça passe.
Donc du coup, là tu vas pouvoir
avoir un barre minimum.
Après comme disais juste, ça va dépendre
beaucoup de ton
infrastructure et de ce que tu veux faire.
Mais globalement
sur une infrastructure classique
on va dire pour du professionnel
le minimum qu'on va vouloir faire
c'est 3 contrôleurs de control plane
2 on va dire serveurs d'accès
Gateway access pour éviter d'avoir
tout le monde qui accède depuis les contrôleurs
et derrière, tu mets des workers
au nombre que tu veux, donc tu peux
partir avec un worker. Donc le barre minimum
on va dire que c'est pour du professionnel
tu vas avoir 3 contrôleurs et un worker
et terminé. Donc au final
t'as pas de gros besoin minimum en fait
vu que justement la grosse force
d'open stack c'est d'être composable.
Après, sur la complexité
il y a un truc qu'il faut comprendre avec open stack
c'est que c'est ultra simple.
En vérité, tout le monde
se fait un monde de ça là, mais c'est
ultra simple parce que c'est
des services qui parlent entre eux
avec un seul langage qui est HTTP
au travers soit d'HTTP directement
soit d'un messaging bus
c'est tout. Tout le reste
c'est accessoire, c'est secondaire, c'est
satellite. Mais vraiment
le cœur du truc c'est
j'ai des services qui parlent entre eux
au travers d'un messaging Q
ce messaging Q il transporte des requêtes HTTP
et les services peuvent s'ils le désire
passer par directement l'externe
et les API en HTTP et dati.
Et là, l'event Q
ça va être quoi qui va être utilisé ?
T'en as 3
t'as RabbitMQ
0MQ et le dernier c'est
Cupid
Je sais que tu veux
Je sais qu'on avait mis du RabbitMQ
mais
ça m'en retrait bien plus
Oui c'est peut-être une seule fois
où on n'a pas trop de problèmes, enfin j'ai pas eu de trop de problèmes avec des RabbitMQ
Oui, RabbitMQ
pour le coup, nous on a déjà eu
des problèmes notamment dans le milieu du jeu vidéo
par exemple
mais c'est en fait vachement relié
à comment t'as installé ça, est-ce que t'as fait le porquis ou pas
et pour le coup
le RabbitMQ est plutôt solide normalement
après oui c'est sûr que
comme toute pièce logicielle, ça a ses subtilités
et ses options
mais globalement
je pense que vraiment il y a un gros blocage
avec OpenSack parce que t'as une myriade de services qui existent
mais globalement faut vraiment voir ça
comme une caisse de Lego
où tu choisis les pièces que tu veux
et finalement
les pièces elles sont compatibles entre elles parce qu'elles ont la même interface
à savoir les petits pico
et ces petits pico c'est juste des API HTTP
qui sont accessibles
soit au travers du RabbitMQ, soit au travers nativement
d'une requête HTTP classique
Et si demain je veux faire mon propre service
est-ce que c'est simple à créer ou pas
parce que, oh les go c'est ça l'intérêt
normalement je vais créer un peu ce que j'ai envie
est-ce que demain je peux créer
moi-même mon propre service pour
je sais pas, j'ai des experts de Kafka
j'ai envie de faire un Kafka à la service
j'ai envie de créer mon propre service
de le rajouter à catalogues
c'est possible ou pas ?
c'est faisable, c'est possible
cet exemple là il n'est pas le bon parce que ça existe déjà
mais...
alors globalement aujourd'hui
il y a tellement de services de disponibles
que ça va être difficile de trouver des services à rajouter
mais oui, oui complètement tu peux le faire
non typiquement on est en train de faire un service
de repository à la demande
parce que comme je disais
un peu en off la avant
nous on a un vrai problème chez nous
qui est dû au contexte de la boîte
on a des contraintes en fait
où tous nos logiciels doivent être offline
et donc on doit être en capacité d'avoir
en interne l'intégralité d'internet
héberger chez nous pour pouvoir rebuild
tout et n'importe quoi
et donc du coup on a créé un service
qu'on est en train de finaliser
pour pouvoir le publier dans la communauté
qui permet en fait de faire du offline
repository à la demande en fait
donc oui c'est possible
après je te cache pas que oui
c'est comme toute communauté
open source, il y a des règles, il y a une gouvernance
il y a des besoins
et donc du coup quand tu vas créer
ton projet
il faut pas que t'arrives les mains vides en mode
je vais le faire, ils vont te dire bah ok vas-y fais le
et puis en fait derrière
si t'apporte pas le projet
et si tu continues pas et si tu prouve pas
par défaut à quand même un minimum de gens
que ce que t'as fait c'est sérieux et intéressant
personne va venir bosser dessus, personne va perdre du temps
finalement
à bosser sur un truc qui n'existe pas
Moi la question que je me pose maintenant c'est alors pourquoi
la si mauvaise réputation d'open stack
pourquoi on le voit si peu
aujourd'hui en fait ça va être ça là
aujourd'hui moi la question que je me pose
si jamais on a quelque chose de composable
et clairement moi des services de redis à the service
ou n'importe quoi
à the service en fait en vrai
dans des sociétés qui ont pourtant
des services de cloud interne, j'en ai vu assez peu
voir même j'en ai vu qu'ils ont recodé le l'heure
de fond en comble
en s'imaginant faire mieux que open stack
Bah alors je vais laisser
par les juillains parce que c'est lui qui a
l'approche la plus
on va dire fraîche en termes
d'expérience et de
du fait qu'il a côtoyé
en fait open stack vraiment récemment
moi j'ai un peu le biais
du survivant
je connais le truc par coeur du coup je m'en fous
j'ai l'impression que ça marche et c'est tout
quoi, donc du coup
je sais pourquoi en fait concrètement
il y a quand même des explications mais je vais d'abord
laisser Julien expliquer son ressenti à lui
Enfin moi
à titre personnel
j'en ai eu quand même pas mal effectivement
de beaux échos quand chaque fois que je parle
du fait que je suis en train de mettre en place
l'open stack dans un milieu associatif
on me dit pourquoi tu fais ça
pourquoi perds-tu du temps là-dessus
ou j'ai pas du tout le sentiment de perdre du temps
effectivement je pense qu'en fait
open stack a malheureusement
en fait une très mauvaise réputation
au démarrage du projet on l'a vu tout à
l'heure la partie réseau de nova
n'était clairement pas la meilleure
il y a plein plein de
problématiques élus comme ça
au démarrage du projet et qu'ils sont stabilisés
dans le temps que très sincèrement
je n'ai pas forcément rencontré dans mon
installation qui est quand même relativement récent
donc je pense que c'est
du fait que voilà le projet
a mal démarré
sur certains aspects techniques et que du
coup les gens font rester bloqués là-dessus alors
qu'en fait comme tout projet
il y a des évolutions qui sont apportées
des pages qui sont apportées aussi
et qu'en fait faut pas s'arrêter là-dessus
c'est complètement ça en fait
pour la petite anecdote
un jour on a eu un souci
dans une des boîtes touche bossée avec un switch
et on appelle
le fournisseur du switch
pour lui demander des renseignements
sur le souci qu'on a avec le matériel
et le gars nous demande c'est pour faire quoi
donc on lui dit c'est pour de l'open stack
il nous dit ça ne sert à rien les gars
open stack ça j'ai aimé marcher
ce à quoi mon collègue du tac au tac
il lui a répondu mais chez nous on a 15 000 machines
qui sont en train de tourner aujourd'hui donc un moment donné
il va falloir réparer notre switch
donc là le mec est gros blanc
puis il nous a dit à tenez la documentation
donc au final oui c'est beaucoup
du ressenti
et en fait ça vient
donc déjà la gênèse d'open stack
il faut bien comprendre que c'est un projet qui à la base
est parti du jpl donc du jet
propulsion lab de la nasa
qui avait besoin en fait de
pouvoir stocker massivement des données
des données qui récupèrent un peu partout sur leur sonde etc
et donc ils ont créé en fait
le premier service
d'open stack qui était le s3 finalement qui est le switch
donc l'object storage
et en fait ils ont fait avec leur besoin
eux donc là dessus
est venu se greffer en conjointement
et une boîte je ne me rappelle plus le nom
c'était pas myrantis
c'était... ah
bref je suis en train de chercher ça
justement avec Rackspace
Rackspace voilà merci
donc Rackspace est venu en fait
en gros ils ont fait ça conjointement
dans le sens où Rackspace était déjà leur fourniteur interne
après je te raconte l'histoire telle qu'on va raconter
mais il y a aussi un point
que tu as oublié dans l'histoire c'est qu'il y a eu un avant
en fait un avant ça
il y a eu l'histoire de nebula et open nebula
avec tous les grammats de la sens
je le compte pas dans le sens où vraiment
c'est distinct d'open stack open stack
ouais mais ça fait pas mal de pas de buzz
en fait dans le sens où en fait les gens ont commencé
à partir vers open nebula
puis après il y a eu un changement de licence etc
qui a fait que tout le monde s'est refaire un message arrière
en fait l'open source et le cloud
voilà il y a eu un petit moment de soubrosseau
entre 2006 et 2010
qui font que quand nous open stack arrive en 2010
voilà il y a déjà eu déjà des soubrosseaux
qui ont fait que tout le monde s'est pris un peu les pieds dans le tapis
et la NASA en effet a préparé sur open stack
pour plus avoir ce problème
et c'est vrai ce que tu es en train
c'est vrai que beaucoup durant le senti alors oui
pour les plus vieux ça va être open nebula qui a effectivement
créé un premier ressenti
la nasa jp l raxplay s'arrive avec ça
il y a en fait un deuxième effet qui se coule
qui est que eux en fait on déployait ça en open source
mais comme tout projet open source
au final ils ont fait ça par bénévola
plus que réellement envie de
de générer une vibe
et un trend cloud
donc ils partagent un truc en fait
qui leur appartient à eux si tu veux
qui répond à leurs besoins à eux
qui en fait attire les gens parce que la promesse
c'est de dire ok j'ai un espace de stockage
qui est scalable et quasiment infinie
et qui en fait est disponible rapidement
et en fait les gens installent ça
en pensant que les gars
avaient fait un petit professionnel
enterprise et compagnie et puis en fait
ils prennent tous les écueils du truc
ou tu dois faire terrain à la main etc
donc du coup ça n'a pas participé
au bon ressenti
et puis en plus derrière quand ils ont continué
à faire la même chose avec des nouveaux services
parce que du coup ils ont publié Nova
qui derrière était là le
compute manager
donc tout ce qui est VM
et gestion des VM
D'ailleurs pour noter quand ça
parle beaucoup à Libvirt en fait en gros c'est plus
une API réseau au-dessus de Libvirt
Libvirt étant après le composant
qui parle réellement derrière
KVM, VMware etc etc
Totalement ouais, exactement
mais au tout début du coup
tu avais des projets indépendants
qui n'étaient pas forcément pensés
pour être génériques mais plus pour être
spécifiques à ces entités là
et donc du coup
au fur et à mesure du temps des gens se sont agrégés
les projets ont continué donc du coup
il y a des nouveaux besoins qui sont apparus
qui ont été comblés avec Kisto
et ensuite avec Nova Network
et en fait tu t'es retrouvé avec
tout un début de période de temps
où clairement
gérer de l'open stack c'était coton
et en fait fallait vraiment
avoir envie et fallait vraiment avoir le besoin
parce que bah
tu te retrouvais avec des bugs
tu te retrouvais avec des problématiques, typiquement
t'avais des VM qui s'arrêtait au bout d'un moment
ça n'avait pas pourquoi en fait
c'est juste parce que chez les gens qui avaient
fait le module ils s'emmerdaient pas, ils avaient mis un skid du leur
et puis bam tu redémarrais
tes VM tous les X temps
ou t'avais d'autres gars qui en fait c'était dit
bah ouais mais moi je suis enclasse, je suis élastique
donc mes VM je les démarge, les arrêtent
et du coup ils frappaient jamais le problème
et donc du coup bah au fort à mesure de toutes
ces remontées de bugs etc
le projet il a quand même mis de rien un gagnant maturité
quand il a gagné en maturité
il est arrivé un moment, il y a eu un moment charnière
avec la release Newton
où tout le projet s'est structuré autour d'une fondation
et où on a dit ok maintenant
on arrête les conneries, il y a trop de bugs
il y a trop de bad buzz
l'outil est quand même ultra utile parce que
il y a une vraie philosophie là-dedans
il y a un véritable enjeu
donc on va arrêter de faire un peu n'importe quoi
et on va structurer tout ça
et donc avec Newton
le pari c'était de dire ok sur cette release là
on va pas rajouter de grosses grosses features
très très changeantes
mais on va restructurer tout le code
et on va refaire en sorte que ça soit rock solid
et que ça marche et à partir de Newton
là on est reparti sur des bonnes bases
avec du code Python qui était beaucoup moins bordélique
avec du code qui était beaucoup plus structuré
avec des process aussi
qui commençaient à arriver au niveau de la CICD etc
et là à ce moment là
on a retrouvé des versions qui étaient vraiment très stables
et depuis Newton honnêtement
toutes les versions sont ultra stables
et ultra fratique à utiliser
ça a changé du tout
du jour au lendemain on l'a vu
on est passé de release, I South Juno
c'était une catastrophe, fallait tout repatcher toutes les 5 minutes
à
It just work
oui parce que ça c'est important, c'est important
on n'a pas trop parlé, tout est fait en pithom
c'était une des choses qui était les plus
les plus importantes au début
il faut le dire, voilà on arrive en 2010
le logiciel arrive en 2010
on n'est pas encore, c'est 2009
go lang donc on n'est pas encore dans cette vibe
de tous les projets qui vont arriver ensuite
tout de façon là à ce moment là
il y a deux gros langages qui se battent pour les nouveaux projets
en tout cas en open source on a du rubis et du pithom
et là on a un logiciel, en tout cas une suite
de logiciel qui décide d'être only pithom
à fond la casque
avec des interdictions, même formelles
de faire quoi que ce soit d'autre dans n'importe quel autre langage
ce qui n'a en effet pas servi
la cause quand on est en 2014-2015
qu'il y a docker qui apparaît
qu'il y a kubernetes qui apparaît
que tous sont en go
avec une base de test assez importante
des logiciels qui tournent plutôt bien
qui sont plutôt performants
et on pat bug en prod du type
qu'on peut avoir en pithom quand il y a un problème
après je pense que là dessus
tu vois il y a deux sujets
déjà le premier c'est que au niveau de pithom
la façon dont fonctionne OpenStack
en fait rentre énormément
dans la philosophie de ce que disait Guido
à l'époque chez Google où il disait
pithom fonctionne aussi vite
que ce qu'il doit fonctionner
et en fait cette philosophie là
elle match plutôt bien avec OpenStack
puisqu'en fait tu as en fait des API
qui vont gérer de façon à synchrone des ressources
et en fait tes ressources, ton but du jeu
vu que c'est dvm etc
c'est pas de les avoir
en disponibilité immédiate à la première
requête mais d'être capable
de les avoir à la demande
de façon élastique et flexible
et donc du coup dans ce contexte
ça marchait très bien
après là où je te rejoins c'est sur le deuxième sujet
ou quand il y a eu
cette interdiction entre guillemets
alors c'était pas une interdiction écrite
mais en tout cas si tu arrivais avec un logiciel
qui était pas écrit en pithom tu te faisais retoquer
et où en fait les mecs
se sont auto préservés mais aussi en même temps
auto tirer une balle dans le pied
parce que ce qui se passait c'est que c'est à une époque
où tout était en train de
de foisonner et on voyait
arriver de plus en plus de projets
si tu veux dans OpenStack
qui était à moitié fini
et donc du coup si tu rajoutes
en plus un changement de langage
au fait que tu acceptes des logiciels à moitié fini
ça devient re le bordel comme c'était avant
donc pour pouvoir se protéger de ça
et se dire bah non on veut un truc
qui juste fonctionne
en fait ils ont été un peu frileux sur les langages
aujourd'hui c'est plus le cas tu peux
techniquement si tu arrives avec un projet
qui est bien foutu en go ou en rust
ça marche mais oui ils ont essayé
effectivement de se protéger
c'est à mon sens bonne philosophie
dans le sens où tu as gardé la stabilité
de la plateforme mais en même temps ça a été
une frustration pour beaucoup de gens
qui étaient moteurs et qui voulaient fournir des services
maintenant c'est vrai que quand tu vois
par exemple des mecs qui arrivaient avec du
SSH as a service c'était un mode
bon pourquoi et pourquoi et puis en fait ils étaient acceptés
et puis en fait le truc est mort au bout de 3 mois
6 mois peut-être je sais pas un peu plus
mais le truc a jamais décollé
ou tout comme le VPN as a service en fait
qui était intégré dans le neutron
qui a été arrêté parce qu'il y avait plus assez de monde
et puis en fait là maintenant il est reparti
parce qu'en fait la boîte qui a
enfin les devs qui ont voulu le reprendre
on dit bah nous on va le sortir en fait
initialement on va le
le refaire vivre mais on va le sortir
de neutron pour en faire un vrai service à part entière
et là je pense que c'est pour le coup plus intelligent
mais du coup quand tu as toutes ces composantes
là et tout ce contexte là mises à
mis bout à bout bah forcément tu te retrouves
à une période de temps où en fait bah vu que t'as un train
de cube qui est en train de grandir
bah toi du côté open stack
tu mets des barrières à l'entrée
tu mets des empêches
enfin des barrières à l'entrée donc du coup
ça frustre les gens et au final bah tu perds en fait
des contributeurs c'est vrai que ça c'est le truc le plus
important en fait pour avoir vécu vraiment
cette différence là puisque moi j'ai beaucoup fait d'open stack
à partir de 2014 kubernetes
voilà première release 1er comite juillet
2014 on a vu vraiment apparaître
donc c'était assez drôle et on voit
aussi un projet open source comme ça
cette espèce de train que peut avoir avec les entreprises privées
pour qui a fait un open stack submit
c'est à quel point
l'argent coulait des murs
de partout et à quel point
tout le monde par toutes les boîtes privées voulaient en être
quoi alors surtout une mire
enti la plupart du temps parce que c'est vrai que c'était
ce qui arrosait le plus mais pas que eux en fait
vraiment beaucoup et c'était vraiment
quelque chose de très important là on voyait
il y avait vraiment une attraction en se disant
c'est bon c'est l'avenir c'est avec ça qu'on va
qu'on va pouvoir vendre de l'infra
vendre un peu tout et tout
et en fait il y a eu un switch très vite
ou d'un seul coup les kubernetes
sont devenus les nouveaux open stack submit
vraiment c'est d'ailleurs on a retrouvé
les mêmes les mêmes acteurs entre les deux
et avec les mêmes choses les mêmes
les mêmes soirées complètement délirantes
voilà il y a la kubernetes qui arrive
là bientôt à paris je vous conseille
même si vous n'avez pas de place
de trouver
des gens qui ont les liens
pour aller vous inscrire à une conférence
enfin à une soirée etc c'est à faire
réellement à faire si vous êtes sur paris
faites les soirées c'est vraiment
quelque chose de très sympa soirée redate
soirée myrventis etc c'est vraiment
des choses sympa à faire mais on voit vraiment
qu'en fait il y a eu ce switch
en fait de traction des boîtes en se disant
là où on peut faire du fric aujourd'hui c'est
sur kubernetes en fait c'est vraiment marrant
ce qui est vraiment marrant c'est qu'en fait
tu t'aperçois que globalement
le logiciel open source ou le logiciel
en entreprise se suivent assez fortement
et en fait les trends
se suivent et se ressemblent parce que
au moment où OpenStack a perdu
le top de son
trend et est devenu en fait quelque part
un truc qui roule que t'as quelque part
mais le nouveau trend c'est kubernetes
en fait c'est le moment
où en fait on a continué à maturer et stabiliser le projet
et finalement c'est là
où il a pris son plus gros essor
financier et contribution
parce qu'en fait ce qui s'est passé
c'est qu'on a perdu énormément
de dev qui étaient
des ressources mis à disposition par Duretat
Ubuntu etc.
Mais en même temps on a gagné
de nouveaux dev qui étaient pure OSS
mais avec une meilleure qualité
étique et une meilleure qualité de code
et donc du coup la stabilité est remontée
et en fait ça s'est un peu compensé
et c'est resté un peu dans le black ground
comme ça en dit les tentes
et donc qui a sauvé OpenStack
c'est sa capacité à offrir des services à la demande
et typiquement les opérateurs telco
ont complètement en fait
sauté sur OpenStack
parce que ça leur a permis
au niveau de la 4G et de la 5G
de pouvoir en fait
déployer de la
de l'infrastructure ultra vite
puisque la 4G et la 5G a cette particularité là
qui est le full software de faille
et donc du coup enfin entre guillemets pour la 4G
mais beaucoup plus pour la 5G
mais au final c'est quand même un peu pareil
et au final
ça a permis à OpenStack de vraiment
gagner son socle
on va dire financier son socle
d'ancrage et là aujourd'hui
vu qu'en fait tu as un renouveau
entre guillemets des besoins
parce qu'il y a beaucoup de gens qui ont compris
ce que c'était cloud, qui ont compris les enjeux
qu'on a actuellement avec ça etc
bah comment ça s'est réintéressé
surtout que en fait
c'est pas si éloigné que ça de cube
et on commence, ça y est les gens commencent
à prendre conscience qu'en fait que l'un et l'autre
sont toujours aujourd'hui
dépendants et il y a toujours un avantage
à l'un et à l'autre et à bosser avec l'un
et l'autre en fait
Ben tu t'anticides, comment tu penses que j'allais dire justement
quel va être justement le
le périmètre, quel va être les
à quel moment on ira plutôt sur un OpenStack
à quel moment on ira plutôt sur un Kubernetes
à quel moment ça sera les deux
quel serait justement l'assemblage qu'on peut y voir
là dedans, je sais pas Julien, toi tu as un avis
par rapport à ça
Globalement je te dirais que
Kubernetes est très bien pour
pour certains besoins
ou typiquement on va avoir besoin de ce qu'il est
ou genre de choses très rapidement
je dis pas qu'on peut pas le faire avec OpenStack
parce que c'est aussi tout l'intérêt de l'outil
mais par contre typiquement
je vois par exemple pour la partie compute
il y a des choses qui sont difficilement passables
même certaines fois en fait d'un point de vue historique
dans certaines sociétés
il y a des choses qu'on peut facilement passer
de machine physique vers des VF
on va avoir dans
OpenStack mais qu'on va pouvoir
difficilement rendre contenerisable
et donc disponible dans des cubes
et donc je pense que là
OpenStack a tout un intérêt
c'est justement pour fournir
tout un focle solide entre-demain
pour éverver ce genre d'applicatif
c'est ce qui se passe chez nous
chez nos restos
l'ébergement de certaines applis en fait
et je ne sais pas possible dans du cube
surtout quand ça tombe sur du Windows
donc OpenStack vient
pour nous fournir
du compute principalement
globalement je pense que
il y a une règle
que moi en tout cas je perçois comme ça
c'est que
enfin c'est pas une règle c'est plutôt
une habitude c'est à dire que quand tu as une entreprise
ou une association qui est mono produit
tu as tout intérêt
à partir sur du cube
puisque en fait tu vas pouvoir
très facilement
avoir ton cube de déployer
ton appli de déployer, sa scale etc
après moyennant toutes les problématiques dont on a
parlé sur Twitter et
sur le Discord mais
globalement quand tu es mono produit
tu as quand même un certain avantage à partir
sur du cube notamment la partie
API unifiée et surtout API
standardisée puisque
ton cube il va pouvoir tourner n'importe où
soit en interne soit dans des cloud providers
soit dans un service manager
de cloud provider ou sur un cloud privé
manager etc et t'auras
cette espèce de API
unifiée entre tous ces fournisseurs
là OpenStack tu pourrais le faire
aussi mais ça serait un peu plus
compliqué
mais là où OpenStack
va vraiment briller c'est quand tu as du besoin
multi produit parce que ton entreprise
elle veut que tu fasses à la fois tourner
ta compta, à la fois tourner
tes produits à toi en tant que
fournisseur de produits mais aussi en interne
tes besoins à DFS
tes besoins Windows
T Linux etc
et donc en termes multi produit là t'as un véritable
intérêt à avoir de l'OpenStack
après tu peux déployer ton OpenStack
dans un Kubernetes
tu peux déployer ton Kubernetes dans un OpenStack
tu peux faire en fait des mix
des hybrides comme ça un peu au besoin
typiquement chez nous on a
un peu de tout c'est à dire qu'on a des BU
qui sont full OpenStack parce que
en fait leur produit est un
peu vieillissant mais contractuellement
on a 25 ans de support donc
il y a un moment donné il faut que ça puisse tourner
ta d'autres BU
elles sont full cube parce que c'est
un nouveau projet qui a démarré il est cloud native
machin etc il est parti sur du cube
ça marche très très bien
t'as d'autres BU qui sont un peu hybrides entre les deux
c'est à dire qu'elles vont faire tourner du cube dans l'OpenStack
parce que leur appli
est en cube mais elles veulent pas se faire chier
à savoir si ça tourne
en interne en externe etc
elles spawnent un cube qui est à la fois dans l'interne
à la fois dans l'externe et à la fois dans
tes provider différents et en fait derrière
elles choisissent avec leurs ségrégations etc
sur la partie OpenStack il y a un truc
qui est un peu plus facile à faire on va dire c'est que nativement
t'as une notion de multi tenant
là où sur cube par exemple si tu veux faire ton multi tenant
ça va être un peu plus pas compliqué
mais c'est une réflexion qui est un peu plus
complexe dans le sens où il va falloir que tu choisisses
est ce que tu veux faire du multi cube
ou est ce que tu veux faire un seul cube
mais avec des clusters
ou avec des autres solutions un peu dans ce goulas
c'est des choix qui sont peut-être
un peu complexes là où c'est vrai
que sur un OpenStack bon bah tu réfléchis pas 30 secondes
bah pas d'air défaut c'est du multi tenant
tu crées un projet, t'es isolé, terminé
n'importe quoi
c'est exactement ce pourquoi en fait
on a choisi OpenStack
plutôt que quelque chose en fait
côté resto du coeur
déjà il y a la partie multi tenant
donc comme je l'ai dit au démarrage
cette association elle est éclatée un peu partout
donc le but en fait c'est que
les autres associations départementales
par bon soit clientes
et soit utilisatrices en fait du service
que nous on vient de juste fournir
de l'infra mais en plus de ça
c'est aussi l'avantage d'être naturellement
multi région
on n'entend vraiment une gestion
en fait des azides, des régions
d'autres qu'on va avoir un peu plus
effectivement sur d'autres solutions
donc ça se paraît c'est hyper pratique
typiquement le but est d'avoir
des ports un petit peu partout en France
pour avoir de la disponibilité
et OpenStack en fait
permet ce genre de choses
c'est directement intégré
avec quelques adaptations à côté réseau bien évidemment
mais c'est quelque chose
qui est naturel avec la piquette
il y a un truc
qui est le plus important même pour vous rejoindre
c'est qu'Ubernetis a été fait dans un temps où il y avait déjà du cloud
c'est à dire qu'en fait
Qubernetis est nativement fait pour tourner
sur du cloud, il y a plein de
fonctionnalités en fait, ou si jamais on n'a pas
tout ce bagage un peu sous-jacent
vont être très compliqués
et on va pas avoir une expérience de Qubernetis
d'ailleurs c'est
une partie aussi, la chose pourquoi les gens trouvent Qubernetis
compliqué c'est parce qu'ils n'ont pas suivi
la traîne du cloud, non pas
d'OpenStack en interne
et quand on fait du Qubernetis
privé et donc Qubernetis devient compliqué
quand on n'a pas un OpenStack
et je connais beaucoup beaucoup de gens vraiment
qui ont trouvé Qubernetis compliqué parce qu'ils n'avaient pas
ils avaient fait l'impasse sur OpenStack
et ça devenait compliqué à ce moment-là
je te rejoins tout à fait là-dessus parce qu'en fait
on a le même
exactement le même comportement
avec OpenStack, c'est à dire que
les gens qui déploient du Qubernetis
font souvent le pas entre
j'ai de l'infra à l'ancienne et je saute directement
dans Qubernetis et je pense que c'est un pack
qui est vraiment très très grand parce qu'en fait ils n'ont pas
intégré et absorbé les notions de cloud etc
et en fait on a le même problème avec OpenStack
où en fait
ils sautent de
j'ai mon infra à papa en barre métal etc
je fais tout manuellement à
je vais installer de l'OpenStack mais en fait entre temps
ils ont pas fait les étapes de consolidation
infrastructure qu'on a pu connaître avec du VMware etc
et donc du coup ils n'ont pas
en fait adopté les réflexes de la virtu
et donc du coup ils n'ont pas non plus
adopté les réflexes du cloud donc ça continue
à creuser finalement encore un peu le fossé
et donc tu te retrouves avec les gens
qui passent de A à Z
en un coup et qui se disent bah
c'est une complexité ignoble parce qu'en fait
ils sont submergés par le
grand écart en fait
et tu le retrouves à la fois sur OpenStack
et à la fois sur Cube et je pense que c'est de là
que viennent aussi beaucoup des
ressentiments qu'on peut avoir sur les deux plateformes
et donc si ces personnes-là en fait
elles faisaient les choses un peu plus par itération
au lieu de vouloir faire directement
j'ai 3 ans et je veux faire un marathon
peut-être que tu vas commencer à apprendre
à marcher déjà avant donc du coup ça serait pas mal
en fait et c'est pour ça que moi j'ai un peu
cette approche hybride chez nous dans le sens où on a
des BU qui vont être très très matures et des BU
qui sont pas du tout matures et donc en fait je m'adapte
aux besoins de ces unités-là
concrètement aujourd'hui
si je devais
faire soit un Cube soit un OpenStack
je pense que honnêtement Cube
est tout à fait capable aujourd'hui de faire
ce que fait OpenStack c'est-à-dire
l'intégralité de fournir les services à la demande etc
on pourrait le faire avec un Cube bien évidemment
qu'il manque quelques services mais ça c'est juste
une question de qui va le développer
finalement
mais concrètement aujourd'hui tu pourras le faire avec un Cube
après la raison de pourquoi
est-ce que certaines fois je vais
partir avec de l'OpenStack plutôt que du Cube
c'est justement ça c'est parce que
en face de toi tu as des gens
qui n'ont pas forcément tout le background
qu'ont pas forcément tout le bagage nécessaire pour aller
de A à Z et donc du coup il vaut mieux partir
de façon incrementale et de leur dire bon ok
vous avez des barres métales, vous avez du switch
vous avez du machin, on va faire ça
vous allez apprendre ces concepts-là, vous allez apprendre
en fait ce paradigme et toute cette philosophie
grâce à OpenStack et une fois que
t'es sur OpenStack que ces gens-là roule
comme disait Julien, vu que c'est des services
qui sont des briques unitaires
tu peux te permettre de dire à tes mecs
de l'infra network bon les gars
on va passer sur de l'automatisation, n'ayez pas peur
vous allez voir on va faire un petit peu de dev ok
mais c'est pas vous qui allez faire le dev
mais concrètement
tu peux prendre ces experts dans un domaine
et leur dire ok maintenant tu vas faire du neutron
on va t'expliquer comment ça marche, on va te faire
le truc, pareil pour les gars qui faisaient
du barre métal tu peux les faire pas laisser
ironique et ensuite derrière à Nova pour la partie
virtual machine, donc ironique pour la partie
gestion des barres métales
et ensuite ironique pour la gestion des virtual machines
et donc ils sont pas si des paysais que ça
mais ils commencent à apprendre un peu
les réflexes de DevOps
de cloud
d'infrastructures hyper-scales et compagnie
et donc en absorbant un peu ces trucs-là
au bout d'un moment t'arrives à avoir
une team qui commence à vraiment être efficace
et puis là à ce moment-là tu peux commencer à les faire monter
en compétence sur du cube etc
et donc à ce moment-là pour les faire monter
en compétence sur du cube facilement
vu qu'ils ont le background d'open stack généralement
ce que je leur fais faire c'est soit je leur fais déployer
du cube dans open stack en vraiment
manuellement tu vois en hard way
soit je leur dis ok si tu as besoin
de manipuler quelque chose qui existe déjà dans open stack
pour comprendre ce que tu vas manipuler après
bah tu vas faire avec Magnum
parce que Magnum c'est le Kubernetes à la demande
dans open stack et du coup en utilisant Magnum
ils arrivent à voir la logique
tu vois de qu'est-ce que tu installes en premier
pourquoi tu l'installes, comment tu génères les certificats, machin, bidule
et donc du coup ils acquièrent en fait
cette connaissance au fur et à mesure comme ça
et c'est vrai qu'il y a aussi un autre point
là dedans moi qui est assez intéressant
étant parlé un tout petit peu au début Julien
c'est la
la division des responsabilités
se dire que tel composant
est la responsabilité de un tel, tel composant
et celui de un tel etc
quand on fait du Kubernetes aujourd'hui même si
il y a des API qui sont la CNAI
la CSAI etc
on a quand même
des Kubernetes en fait où on a beaucoup moins de composants
déjà en interne mais où les
API sont, enfin les contrats
sont très très fins
enfin les contrats sont très très liés en fait
l'un à l'autre et en fait c'est rare
que à l'intérieur d'un même cluster on est plusieurs CNAI
qu'on est plusieurs CSAI etc
on peut le faire, c'est tout à fait possible
c'est juste assez compliqué
et c'est peu recommandé de le faire
le but d'un Kubernetes c'est pas de se prendre la tête
c'est de se dire j'ai besoin d'un disque
mon cluster il est configuré comme ça
j'ai un disque point j'ai pas envie d'aller
faire du fine tuning dedans
et en fait le problème qu'on a aujourd'hui
en fait de vouloir faire de l'open stack avec Kubernetes
c'est qu'en fait on se retrouve avec le pire des deux mondes
où on se retrouve avoir des API qui sont quand même
qui deviennent notre récorrelés les unes avec les autres
sans gagner
les atouts de la
de la flexibilité etc
quelque chose aussi dont on n'a pas trop parlé mais
qui est important c'est que
les upgrades dans OpenStack alors ça a été
tout un sujet pendant très longtemps mais aujourd'hui
KINDA works
c'est-à-dire que je peux upgrader mes composants
les uns à la suite des autres
c'est même pire que ça aujourd'hui les upgrades
moi aujourd'hui en moyenne on fait
à peu près 35 upgrades par jour
chez nous parce que
en fait on a toujours alors update plus
upgrade mais on fait 35 updates
upgrade on va dire mélanger en même temps
par jour puisque en fait on a toujours
des besoins de nouvelles régions
de nouvelles AZ et donc du coup on va
par exemple changer
une option d'un nova compute
en fait t'asseille elle va mettre à jour tout le monde
et puis ça te fait tout seul et en fait ce qui se passe
c'est que t'acquiert en fait
avec ça une tranquillité
d'esprit qui est assez agréable puisque
aujourd'hui ça se ressent sur ton uptime
et sur en fait tes astreintes
sur les gens qu'est-ce qu'ils font dans la journée etc
et en fait tu coupes tous les pompiers
pire-mann en faisant ça et c'est assez ouf
et en vrai le upgrade
au fil de l'eau dans OpenStack maintenant
ça marche vraiment
c'est même plus une question
et en fait ce qui est intéressant c'est qu'en plus tu peux mettre à jour
une partie de tes composants
vu que c'est des brigues donc en fait
tu peux mettre à jour si tu veux uniquement ton onva compute
parce que t'as besoin d'une nouvelle version
avec une nouvelle feature spéciale etc alors oui
tu vas car même vérifier avant les
compatibilités descendantes et ascendantes
mais globalement tu pourrais envisager
des trucs comme ça on le fait assez peu
parce qu'au final serait que c'est se rajouter
de la dette pour rien mais globalement tu pourrais le faire
typiquement
chez un éditeur de jeux vidéo
on avait fait un truc qu'on appelait le frankencloud
ou en gros l'OpenStack
qui était déployé à la base
c'était un OpenStack full bar métal
avec derrière les services déployés sur le système
depuis le package manager
de la distribution
et en fait à un moment donné on s'est dit
il existe un outil dans OpenStack de Lifecycle Management
qui lui se base sur des containers
plutôt que sur les packages manager
ça nous éviterait d'avoir à faire
des migrations et des updates
compliquées et en fait ce qu'on va faire
c'est qu'on va au fur et à mesure de
l'eau changer les
services qu'on a sur les machines
en containers et en fait t'arrives
à avoir les deux qui vivent ensemble
parce que tu as du coup ton service
par exemple qui stone qui va être dans le container
et ton service nova qui lui est un package
et en fait au fur et à mesure de tes migrations
bah hop tu le passes dans un container
et en faisant ça en fait bah tu te fais des upgrades
et des updates qui sont sim less
et qui sont vraiment au fil de l'eau
et tu peux faire ça plusieurs fois dans la journée
parce qu'au final derrière t'as un instrumentaire avec tes CI CD etc
Oui c'est un point important à dire
c'est que enfin on en a parlé mais
il faut vraiment l'avoir en tête
c'est des logiciels en piton
des logiciels qui se mettent extrêmement facilement dans un container
et donc si c'est dans un container
ça veut dire qu'on peut le déployer
avec du Kubernetes
et donc en fait on peut très bien avoir ce leverage
comme ça où on se dit que
Kubernetes c'est très peu de service
c'est très léger pour le coup c'est très fin en fait comme abstraction
à la différence d'un OpenStack
ce qui fait qu'on peut très bien l'utiliser
pour spawner ses premiers composants d'OpenStack
donc on met un Kubernetes
on spawn quelques containers mais vraiment
pas énormément ça doit être une vingtaine
une trentaine de containers qui nous permettent
d'avoir notre control play in OpenStack
et après voilà le control play in OpenStack
lui il va aller piloter des dizaines
des centaines des milliers de machines hautes
pour faire tourner des VM
et à l'intérieur de ces VM après
on peut installer des OpenStack
à l'intérieur de ces VM également
mais typiquement quand on parle même de Kubernetes
les gens qui ont des Kubernetes
Vanilla, Bar Metal etc
ce pose de problème très vite de comment tu fais de l'autoscaling
comment tu fais du FinOps par rapport à ça
ben là c'est un peu wallou
comment tu fais de la facturation
comment tu fais tout ce genre de choses là
en fait il y a même
toute la notion d'IAM
c'est que aujourd'hui
les Kubernetes en fait
est vraiment désigné et fait
pour tourner autour d'une équipe
c'est vraiment ça
même si il y a une notion de namespace
c'est qu'un espace de nom
c'est pas un tenant
ça c'est pas appelé tenant
ça c'est à ma privil'ère vraiment de namespace pour cette raison là
là où
pour le coup OpenStack a cette notion de tenant
très verrouillée
qui sont partagées par tous les composants
qui le connaissent, qui le prennent en compte
qui sont sécurisés par rapport à ça
on peut mettre des systèmes de facturation
qui vont, qui sont bien et tout
enfin on a vraiment toute cette notion
vraiment très forte d'isolation
et même le réseau
là où dans Kubernetes on a un réseau flat
où on peut avoir de l'isolation
au niveau d'un E qui vont être fait globalement
avec des rugby PtBalls
même si on peut le faire avec du BPF etc
dans le cas de OpenStack
historiquement même on allait
jusqu'à piloter les switch
jusqu'à vraiment piloter
toujours le cas puisque nous typiquement on a des zones
où on fait ça, où en fait en gros
tu vois par exemple quand tu es en fait le fournisseur
d'infrastructure et que tu n'es pas le consommateur
d'un cloud, quand tu es le fabriqué en un cloud
tu vois c'est problématique de dire ok
mais quitte de la poulet de l'oeuf quand je fais
mon bootstrap
en fait à un moment donné
dans ton bootstrap
il faut que tes switch soient instrumentables
parce que ça fait partie de ton infrastructure
ça fait partie des ressources que tu as besoin
dès le départ de pouvoir piloter
et donc nous on a cette capacité aujourd'hui
sur une nouvelle région qu'on ouvre
à partir du moment où on a
la nouvelle région qui est disponible
on va sur place, je prends le laptop
je fais bootstrap et bouffe la région
y compris les switch, y compris le peering etc
et voilà cette notion de tenant
je pense que beaucoup doit la voir en tête
et ouais et sur
deux points la que tu as cité
les tenant effectivement
une isolation galvanique qui est beaucoup plus importante
et ça c'est vraiment quelque chose que les gens recherchent
alors après est-ce que c'est à tort ou à raison
on peut avoir la discussion parce que
réellement il y a des fois où tu te dis oui mais bon
les relations en fait on s'en fout concrètement
sur la partie network notamment
moi j'ai beaucoup de gens qui nous disent
ouais mais moi je veux pas voir l'adresse IP
mon petit voisin bon concrètement avec les network policies
etc, les bpf et compagnie
t'as pu aujourd'hui cette notion
de soucis mais admettons que la personne
elle est butée bornée pour xy
et que t'as pas envie de rentrer
dans des débats technico-techniques infinis
bah à un moment donné tu vas dire ok bon bah
je vais te filer un tenant dans open stack
tu seras complètement isolé des autres parce que
t'es dans un vx LAN qui est isolé
dans un gené v qui est isolé
enfin peu importe l'incapacitation que tu veux
et oui effectivement t'as cette isolation galvanique
et sur la partie upgrade
là où tu parlais de Kubernetes qui te permet
de monter tes versions etc alors au delà
de Kubernetes tu peux me le me faire avec
des barres métales et du docker parce que c'est ce que fait cola
typiquement cola il te prend une collection de barres métales
il t'installe docker dessus et il gère
en fait tes conteneurs dans des docker
donc en gros ça fait
un petit peu ce que ferait un Kubernetes
sauf que au lieu de le faire en temps réel
ça le fait au moment où tu le demandes d'exécution
dans Kubernetes aujourd'hui
un avantage qu'on a c'est qu'on peut faire tourner
les sidecarts ou les run ones
et donc du coup ce que tu peux faire c'est que
tu peux dire bah ok j'ai la version Victoria
je veux passer à wallaby
mais en fait je vais avoir un switch
de mes conteneurs donc je vais rajouter mes conteneurs wallaby
je vais passer rapidement
en fait je vais éteindre mon Victoria
je vais passer mon sidecard de management
qui va en fait faire le grid de mon schéma de base de données
et terminer
et en fait derrière ton service il n'a pas eu une coupure
en fait il faut voir quasiment OpenStack
comme un logiciel
avec plusieurs services je n'ai pas plein de micro services
parce que pour le coup ça me met pas de sens dans ce cas là
mais on a un service
on a un logiciel qui est juste avec plusieurs services en un
clairement moi ce que je me dis à chaque fois
c'est que si jamais vous ne savez pas installer OpenStack
enfin faites pas d'infra que
enfin c'est pas votre taf
ou faites de l'infra à l'ancienne
mais touchez pas un logiciel moderne qu'on va avoir
dans n'importe quelle entreprise
d'une taille à peu près raisonnable et sérieuse
qui fait des logiciels compliqués
mais tu vois ça c'est un point qui est marrant aussi
c'est que tout le monde attaque assez rapidement OpenStack
en mode ah ouais mais c'est du micro service
ah le micro service versus monolithe
concrètement je pense que les gens
ont aussi un gros blocage avec ça
qui est juste idéologique dans le sens où OpenStack
oui c'est un micro service parce que en fait
c'est une myriade de services qui parlent entre eux
au travers du messaging bus
mais globalement
ton novac compute c'est un service monolithique
il ne fait qu'une chose et il le fait bien en fait
donc c'est oui il y a une myriade de logiciels
mais t'es pas obligé de tous les installer
pour commencer et surtout
en fait un micro service
c'est simplement un monolithe réduit
à sa plus petite échelle en fait
donc au final si t'arrives pas
à comprendre ce principe là et si t'arrives
à te dire que OpenStack c'est compliqué
parce que c'est du micro service mais derrière
tu me fais du Kubernetes avec whatever service
que tu fais tourner avec les CRD et compagnie
tu fais la même chose en fait concrètement
donc au final
cette excuse du micro service
oui du micro service versus monolithe
elle est un peu intergimé et recevable
dans le sens où vraiment
tu installes ton control plane
et tes workers, datit
alors oui il y a des gens
qui s'amusent à faire des designs très compliqués
où ils vont spliter
le novac conducteur qui ne vont pas le mettre
sur le control plane, ils vont le mettre plutôt
sur des auxiliairies, des trucs comme ça
certes tu peux vers ce que tu veux
et au moment où ton logiciel tu le mets là où tu veux
et il sait discuter
avec le messaging bus et la database
bah tu le mets un peu où tu veux
mais ça après c'est de l'over engineer
et tu peux pas reprocher un logiciel d'être over engineer
par la personne qui va le déployer
l'intégrateur tu vois ça c'est vraiment
et Julien je sais pas si c'est quelque chose en plus là-dessus
t'as moins rajouté ou ?
pas spécialement
Super on va essayer de finir quand même
avec l'avenir qu'on verra à OpenStack
je sais pas si vous avez des choses
quelles est l'avenir qu'on pourrait attendre
parce que alors pour parler un peu d'avenir
j'avais fait une interview de Red Hat il y a pas très longtemps
où il me disait que eux
ils avaient commencé à moins pousser
OpenStack
aussi parce que la base installée est déjà là
en fait il y a peu de gens qui vont aujourd'hui
sur OpenStack et que pour
pousser plutôt sur l'OpenShift qui a un cul-cube vert
notamment, autre sujet
mais justement quelle serait l'avenir
là aujourd'hui d'OpenStack ce qu'on peut voir
est-ce que ça va rester comme ça parce que ça fait très bien
dans son taf ou est-ce qu'on pourrait avoir
de choses, un concurrent ou pas
à mon sens
il y a une chose que OpenStack
pourrait faire qui serait intéressant
d'affaire dans l'avenir c'est
de se dire ok d'ailleurs ils ont déjà
commencé à faire ce move là puisque
si tu regardes bien le marketing de l'OpenStack Foundation
ou l'Open Infrastructure Foundation maintenant
comme elle s'appelle en gros
ils vont te parler de Loki, Loki c'est
Linux, OpenStack, Kubernetes et
je sais plus que c'est lui
et en fait aujourd'hui
les gens qui disent ouais on a
où on va abandonner OpenStack parce qu'il
y a Kubernetes, je pense qu'en fait
ils se trompent de route dans le sens où
ton Kubernetes il faut continuer à le faire évoluer
et à le faire vivre ça c'est sûr mais en fait
rien n'empêche de dire que OpenStack
c'est simplement un logiciel comme un autre
et qu'en fait tu vas le mettre dans ton Kubernetes
et il va te rendre les services à la demande
et il va créer en fait ton cloud dans ton Kubernetes
et en fait tu peux très bien penser
à un service OpenStack ou à l'ensemble
des services OpenStack de la même façon
que quand tu installes je sais pas, moi ton opérateur
MySQL ou je sais pas quoi
sur ton Kubernetes c'est la même chose
aujourd'hui au lieu d'avoir un opérateur
MySQL, tu auras un opérateur
Keystone par exemple
je pense que ça serait
la voie la plus sage
honnêtement ils sont déjà un petit peu parties là-dedans
puisque aujourd'hui se battre contre Kubernetes
n'a aucun sens, les deux en fait
devraient se nourrir les uns des autres
et du coup je pense que ça va aller vers
là-bas, ce qui serait intéressant c'est que
on fasse un peu le ménage au niveau des
des barrières à l'entrée, au niveau de la contribution etc
et ça c'est une discussion
qui est un peu problématique
un peu ougeuse dans la communauté
Et toi Julien je sais pas si tu as quelque chose
que tu verrais, est-ce que tu le verrais aussi
de par l'expérience que tu as
peut-être un peu plus récente et que tu le vois avec des lieux
à neufs
Alors justement par expérience
oui je le contéresse
en quoi de problème, d'ailleurs c'est ce que je fais actuellement
je dis ça d'être supporter on va dire
d'open stack en interne
côté d'hier pour le proposer
Globalement
il y a quand même des choses que j'aimerais bien
peut-être qu'il se soit amélioré
et ça c'est plus par des retours utilisateurs
c'est une première
sur lequel on tombe alors que comment tu es
d'open stack
c'est la web 8, horizon
et globalement plutôt play school
la première fois on connecte dessus
ça fait un peu jouer, de toute façon ça a été
un peu fait
à la rage
le projet
a malheureusement
elle a pas eu beaucoup d'évolution de ce que je l'ai pu voir
alors je ne sais pas non plus
dix ans d'expérience on va dire
sur open stack mais c'est globalement le point d'entrée
en fait lorsqu'on arrive
sur notre infra open stack et ça peut
remuter
certaines personnes de pas avoir quelque chose
on pourrait dire mes claires
elle est tout à fait fonctionnelle mais c'est vrai que c'est pas forcément
quelque chose d'iltramoderne
et ça a contribué aussi d'ailleurs
à l'image de
d'open stack en un certain sens
c'est que c'est vu comme un outil qui est pas forcément hyper moderne
alors qu'on ne fait pas du tout
c'est juste
pour le coup une deep thin qui est malheureusement
c'est quelque chose
qui est
monté entre lui mais par
justement
c'est marrant en plus quand on compare au Kubernetes dashboard
qui est connu pour un truc qu'on ne veut jamais
installer
ça c'est marrant comme on a vu comme étant moderne alors que le Kubernetes
dashboard on ne veut pas l'utiliser
tout le monde te dit c'est un peu en repoussant
si jamais je le vois en mode
il laisse le Kubernetes dashboard non mais ils n'ont pas compris comment marcher
à cube il est étonnant de voir la différence
avec eux et c'est vrai que là pour le coup
sur ce composant là
c'est vrai que les très gros acteurs ont tous recodé le leurce
pour ça qu'ils ont moins investi dans cette version
en paix de tour
mais en fait
sur cette partie là c'est
une vraie problématique parce qu'en fait
déjà tu vas avoir un problème
c'est que dans le monde du dev tu vas avoir la
trend bon ben comment est ce que je découpe
mon interface de mes back-end
vu que tous mes services sont à Piaille est ce que vraiment j'ai envie qu'horizon
ça soit des pages HTML qui sont générées
avec du angular dedans
je suis pas bien certain
et du coup en fait ça ajoute de la complexité parce qu'au final
tu te retrouves à avoir des contributeurs qui doivent à la fois comprendre
ce qui dev en Python
plus donc du Django
plus derrière de l'angular Js
alors qu'en fait
concrètement tu as des API de partout
donc tu pourrais en fait générer totalement
ton dashboard en ReactJS avec un Redux
et totalement te passer
d'avoir un savoir qui te génère ton front
finalement donc déjà tu as cette question là
HTML HTML mix
ouais ou HTML mix par exemple
mais du coup
tu vas avoir l'autre souci qui est en fait
dans horizon à chaque fois
tu vois tous les produits open tag
tous les produits que tu n'as rien dit c'est ce que tu disais tout à l'heure
c'est à dire que c'est les produits qui sont faits par des devs
et des ingénieurs
mais qui se trompent de clients
c'est à dire qu'ils pensent que leur client
c'est eux-mêmes alors qu'en fait leur client
c'est des utilisateurs finaux
et donc du coup ce qui va se passer c'est que
tu as cette différence entre
ce que l'ingénieur il a dans sa tête et il se dit bah ouais
moi je vais cette fonctionnerie
et en fait derrière ce qu'attend le client quand il arrive
sur le dashboard bah c'est pas ça
et du coup typiquement tu vas avoir le client
là maintenant sur horizon ça va
parce qu'il y a encore assez de devs etc
donc c'est cool tu vois ça a quand même
des mises à jour etc
mais globalement si chaque produit
qui est indépendant ne fait pas
son plugin pour horizon parce que c'est ça aussi
qu'il faut voir c'est que la philosophie de
plugabilité de open tag s'applique même à horizon
donc si par exemple ton DNS as a service
fait correctement son core service
mais qui en fait son plugin horizon
il le fait comme n'importe comment
mais en fait ça va être
ça va participer à la
à la mauvaise réputation
finalement d'horizon alors que quelque part
c'est pas vraiment la faute d'horizon
et du coup tu vas te retrouver dans des situations
ou par exemple Glens qui est le manager
des images tu vas dans horizon
tu peux uploader ton image avec un petit bouton
tu vois par contre pour la downloader
parce que je sais pas moi un temps que l'utilisateur
final t'as envie de downloader ton
raw ou ton cuco 2 là
en fait tu peux pas parce qu'il y a pas de bouton
t'es obligé de passer par la CLI
donc là tu te dis bah attends il y a un délire
donc moi j'ai essayé de faire le patch
je suis allé voir sur le launchpad
on a poussé on a poussé
il y avait un gars qui avait déjà fait le patch avant moi
je suis allé voir
58 revisions
tout le monde tourne autour de
ouais mais la classe utilisée pour le bouton c'est pas la bonne
mais les gars poussez la release
et ensuite derrière vous pacherer
arrêtez de vous prendre la tête
est-ce que la classe utilisée par le bouton
est pas la bonne est-ce que l'image au lieu d'être
une petite disquette ça doit être une flèche vers le bas
je veux dire à un moment donné ton utilisateur
ça fait 15 ans qu'il attend ça
donc oui c'est un logistiel open source
mais il faut arrêter de se voiler la face
c'est utilisé par des utilisateurs
finales d'entreprise
c'est pas madame Michou qui s'amuse à s'installer
à un open stack chez elle dans sa cave
il faut arrêter donc du coup
quand on arrive à des trucs comme ça
forcément tu en arrives à des aberrations qui font que derrière
t'as un ressenti qui est pas fou
et c'est là un peu la limite de l'OSS
par rapport à un logiciel comme Proxmox
ou en fait t'as un
t'as un développeur principal et une boîte derrière
qui dit bah moi je suis en dictature
et je fais ça ça ça ça et ça comme futur
là c'est une démocratie
et comme toute démocratie c'est ultra lent
faut que tu discutes avec des gens
faut que tu ailles sur le review
que tu fasses ton patch moi là tu as un patch pour redesignate
il ferme 2 3 4 5 6 bug
on en est au patch 7 21
il a été ouvert le
23 mars 2023
et on est le
22 septembre 2023
les CIs sont passés elles sont succès
c'est tout mais j'ai encore le patch qui passe pas
parce que t'as un gars qui dit
oui mais là la virgule dans le document
t'en vas de baf on s'en fout un peu en fait
toujours un peu le problème par rapport à ça
tu vois si tu as des autre choses que vous aimeriez rajouter
tu seras au check
beaucoup d'autres choses à parler sur open stack
et plein de choses dans tous les services
notamment qu'on a abordé
dont on pourrait parler
d'ailleurs si vous voulez en parler n'hésitez pas à rejoindre le discord pour en discuter
ou flinges iosect a un autre discord
spécialement pour les open stack
on a un discord effectivement pour les open stack
déjà si vous avez des questions
est-ce que quelqu'un a des questions dans les auditeurs
et effectivement
on a un discord que je mettrais dans le channel
attend hop
je vais mettre le façon en description du podcast
pour ceux qui l'écoutent
beaucoup plus de monde qui l'écoutera
que de gens directs
c'est éternel problème des projets osse
qui ont des interfaces éclatées qui auraient été très compliquées
il y a des ex de suiz et contraintes
oui exactement
on a ce problème là effectivement
sur lui, lui x c'est super compliqué
parce que tu as plein de contraintes
tu as plein de problématiques
qui sont à la fois du dev et de lui xui
et les deux n'arrivent pas à s'entendre assez régulièrement
donc c'est clairement
il y a une initiative
autonome
qui s'appelle
il y a un dashboard
qui n'est pas horizon
qui est 100% compatible avec OpenStack
et qui est
le renouveau entre guillemets
de horizon qui s'appelle
Skyline
Skyline exactement
justement c'est
bonnes 30... enfin
tu fais bien d'en parler parce que justement
nous notre côté, côté resto
justement comme ça il y a une certaine frustration
vis-à-vis de l'Uine
où on est passé sur Skyline
donc c'est très très bien
du coup tu vois Skyline
ça rejoint en fait ce que je disais
c'est à dire que c'est une SPA React.js
au lieu d'avoir en fait
tout un bordel Django générer
un Angular.js qui générer de l'Urature
et au final le projet de Skyline
il est vraiment sympa
bon après tu as encore besoin d'installer
un générateur
de static page
mais globalement il pourrait en fait filer
une CI qui dit ok je génère la static page
pour tout le monde, tu prends ce targe et ça
là tu lui déploies dans ton Swift terminé
ce qu'il faut avoir un truc c'est que
dans OpenStack
on a quand même l'habitude
de hit your own dog food
parce qu'au final tu peux dans Swift
activer l'option de static web
comme tu le ferais sur une github page
et du coup tu pourrais en fait
envoyer dans ton conteneur
admin la UI
de ton dashboard en fait
et t'auto héberger ta UI
sans avoir besoin de l'héberger
en tant que service en elle-même
ok bon c'était
c'était très intéressant
donc n'hésitez pas si vous avez des questions
donc le lien en description pour
ce discord là
le discord d'OpenStack
et si vous avez des questions de toute façon
retrouvez-les tous sur Twitter
n'hésitez pas à les pinger
et voilà
merci à vous de vous en tout cas d'être venu pour en parler
je pense que ça aura
pas forcément donné beaucoup d'informations
à ceux qui connaissent déjà OpenStack
mais déjà donner un peu une vision
peut-être donner des arguments quand il faut en parler
en interne mais je suis sûr qu'il y a beaucoup de monde
qui auront appris les intterns
et pourront après
les plus se renseigner
et vous poser des questions
c'est jamais y'a quoi que ça va ça
c'était super cool d'avoir le feedback
de Julien sur son projet
et de voir qu'en fait même en 2023
on a des cas d'usage
ou on a des gens qui du coup
au travers de leur taf on l'habitude de bosser
avec un Kubernetes et qui en fait
finalement derrière sur d'autres usages
vont aller vers un OpenStack parce que
ça fit plus avec le besoin
ça c'est cool
merci à vous deux
merci à tout le monde