Reprise du message précédent :
S&R Pro c'est une vaste blague

+1

bonjour,

bonjour,

 
Dans la nuit j'allai répondre que moi, j'aime bien la solution BGP pour maintenir mes tables de routage et tout sur le même "subnet", comme ça, t'alloue les IP et c'est ton AS qui fait le routage comme un grand avec tes switchs L2. Comme ça, plus a se poser de question si ton réseau est assez gros pour encaisser la charge : la réponse sera toujours oui.

Owi
Le genre de solution que j'adore, mais faut des gens avec un minimum de bagage en réseau pour déployer/maintenir/utiliser

 
nous on fait tout en BGP, meme en interne, y compris les IPs de service en /32

moi je suis totalement opposé à bgp dans les entreprises en interne pour des questions de temps de convergence
 
après il y a le souci d'avoir la compétence pour gérer le protocole

 
Temps de propagation des routes tu veux dire ? En interne sur 2/3k IP, la propagation tu peux bien la mettre avec un refresh de 2 minutes, c'est pas comme si c'était dramatique d'augmenter ta charge en interne sur tes propres AS.

Pour du réseau interne standard (je parle pas d'infra entreprise type cac 40 avec interconnexions complexes ente plusieurs blocs). Un simple process OSPF me semble tellement plus simple que de gérer des AS avec des liens ibgp et des attributs pour influencer le routage...

Pour des réseaux de 5000 machines: 1 subnet. (quelques vlans mais uniquement sur des interfaces supplémentaires sur certaines machines)  
Routage L3 fait par le Nexus en haut de l'archi et roulez jeunesse

preums

io

Hello,
 
Jsais pas si j'ai déjà posé la question (obviously j'ai oublié la réponse si tel est le cas ) :
 
Peut on utiliser kickstart pour Debian de la même manière que pour Ubuntu ?
 
Exemple d'un Kickstart qui me plait bien dans l'esprit : https://github.com/frederickding/xe [...] -server.ks
 
J'ai vu que ça marchait pour CentOS et Ubuntu, mais je trouve pas de réponse claire pour Debian

ce script

Dans le principe, j'aimerai pouvoir proposer un "one click" install dans Xen Orchestra, en passant une clef SSH et que ça installe les Xen Tools au vol, et sans poser de questions pendant l'install (donc en mode "Cloud" )

http://www.mediapart.fr/journal/fr [...] aint-denis
 
huhuhuhu

https://cloudinit.readthedocs.org/en/latest/ ?

 
et th2 sont en dernier appel vs mairie/voisins pour les tours réfrigérantes. si eux ils coupent, bye bye internet

 
Ça risque d'être sport mais jvais voir jusqu'où je peux aller dans ce sens.

j'ai vaincu

Bon ben ça va pas des masses pour ce que je voudrais faire. Je précise ma pensée :

Dans le process de création de VM, au lieu d'avoir que des templates compliqués (enfin parlant que pour un admin), je voudrais juste proposer quelques distros « majeures » avec différentes saveurs (RAM/Disk/CPUs), et pouvoir configurer tout depuis le panel de création. Autrement dit, rien à renseigner pendant l'install « système » de la VM dans sa console.

Concrètement :

• distro
• choix parmi quelques saveurs configurables par un admin (RAM/CPU/espace disque)
• nom d'hôte, clef SSH

C'est tout, puis "Go" et voilà l'instance spawn toute seule, et retourne son IP et puis comment y accéder. Plus tard viendra le DNS par exemple, mais c'est autre chose.

L'idéal c'est de pas avoir à stocker une image pré-existente qui pèse « lourd » mais plutôt de suivre une process d'install automatisé, qui puisse installer les Xen tools, la clef SSH, le nom d'hôte etc.

Preseed : assez merdique à maintenir et pas très flexible, mais dans le domaine du faisable
Kickstart : plus clair déjà mais que CentOS et Ubuntu (bon après pourquoi pas...)
Cloud init : chouette mais faut déjà que le paquet soit installé dans la distro pour en profiter

Rappel : Xen Orchestra c'est pas du SaaS, donc si j'ai des images que j'ai à faire passer au client, il faut que ça soit downloadé à un moment. Des scripts KS ou Preseed c'est tout léger comparé à une install de base, même d'une Debian.

edit : sinon je peux toujours builder un ISO à télécharger (ou built-in dans XO) pour booter sur une Debian/Ubuntu/CentOS qui gère le cloud config de base, comme CoreOS. Cf https://github.com/frederickding/Cloud-Init-ISO

Franchement au dela de ce que tu décris (choix CPU/RAM/Espace, distro, clé ssh à la rigueur) c'est puppet ou équivalent, sinon c'est pas maintenale

Bah le choix de la saveur c'est trivial puisque c'est dans le process de création de VM actuel, qui passe ça à la XAPI. La partie compliqué c'est de dire à l'installation de la VM que je veux passer la clef SSH et installer les Xen Tools (une fois que j'ai les tools, j'ai 36 solutions pour communiquer des infos au guest, y compris la clef SSH).

edit : punaise, même une Ubuntu Core c'est 300 Mo

Jme demande comment font les providers de Cloud : image pré existante avec cloud config ou install avec kickstart/preseed/autre.

edit 2 : jsais même pas si j'arrive à être clair, j'ai trop de taff en ce moment

Toutes les images prévues pour openstack incluent cloud-init de base

Comme ça, c'est pour ça que je t'ai pointé dessus  

Donc ça veut dire un gros morceau à récupérer une fois quoi

C'est moche

edit : c'est quand même fou que personne s'est sorti les doigts pour pondre un truc valable et léger, même les containers l'image de base c'est pas non plus très light malgré la techno.

Je suis désapointé

T'as bien regardé qui faisait de l'OpenStack aujourd'hui ? Tu as pas du bien comprendre ce qu'ils entendaient par lourd

Ben c'est à dire que même un debootstrap de base ça pèse bien 200 à 300Mo, alors bon, difficile d'aller en dessous.

Pis je vois pas le problème en fait

Dans les grosses structures, c'est IP > PXE avec une image PE poussée via réseau/provider.
C'est le PE qui fournit les infos qui vont bien pour l'install de la distro ensuite (que ça soit du windows, linux, whatever qui supporte la virtualisation, ou pas d'ailleurs)
Les protocoles sont plus bas niveau et mon abstrait (PXE < image + clé SSH) et donc a réfléchir autrement.
En full virtualisation/cloud, openstack/puppet/chef/salt, mais ça fait encore trop usine a gaz pour avoir de l'abstraction pour fournir du clé en main clickodrome a un client final. Faut encore un minimum de bagage si tu veux conserver du KiSS aussi bien dans l'infra qu'a l'utilisation.
 
Petite évolution : images stateless possible avec systemd assez facilement (possible aussi sans, mais ça reste tricky et a base de chrooting/scripting, sans utiliser systemd, l'un des gestionnaire de paquets pouvant faire ça serait portage-qui est ma solution actuelle : boot sur PXE + configuration d'une image PE qui pousse un chroot minimal qui va charger l'overlay qui va bien suivant les choix de profilage)
 
Edit : si t'arrive a faire se que tu veux dans un format limité en taille, ça pourrait faire un joli carton et ça serait une jolie feature très très très intéressante niveau infra.

Si tu savais, en ce moment j'ai l'impression d'être le bureau des pleurs des gens qui ont échoué à intégrer OpenStack (3 discussions par jours avec des gens différent sur le sujet, et d'un peu partout dans le monde !)

Le debootstrap le client le fait sur son infra comme un grand, il va pas fetcher 300 Mo sur le/les serveurs de Xen Orchestra pour avoir une distro compatible avec le clickodrome qui marche

Ou alors faut que je puisse ajouter mon grain de sel post-install, ce qui veut dire qu'à un moment où un autre la distro pull ces données quelque part.

Tiens systemd stateless j'y ai pas pensé. Ta une bonne doc/use case concret quelque part ?

 
Téléphone moi si t'en trouves un qui a vraiment réussi

Y'en a bien un ici sur ce topac qui a réussi il me semble Jsais plus qui par contre

edit : jsais même plus dans quoi tu bosses, t'en vois souvent des users d'OpenStack ?

 
Les providers de cloud ont des miroirs locaux, des images pré-existantes (coucou les AMIs) etc

Ouaip, mais du coup une image par taille de disque ? Car même si je fais un template, il aura une taille mini fixe. Faudrait que je resize le VDI quand la personne créer son instance (faisable je crois avec la XAPI) puis que le cloud config étende jusqu'à la nouvelle taille (Cloud Config le fait).

Ça me parait une solution.

Mais c'est vrai qu'après reformulation, j'aurai aimé un truc comme ça :

• click du user dans son XOA pour créer l'instance qui va en fait juste récupérer une recette chez nous (sur nos serveurs)
• cette recette va permettre de taper dans les dépots standards des distros (donc chez nous on a que quelques Ko de recettes)
• et builder les trucs qui vont bien à la volée

Mais bon, en l'état actuel des outils/technos, ça existe pas comme je voudrais (pas regardé systemd encore )

Bref, jvais enquêter pour me faire un template CloudInit ready et voir si je peux faire grossir le disque

edit : merci à tous pour vos suggestions Sur Sys/Rez Pro, je serai parti sur un SCCM et un Windows 2018 Beta

Preums.

bonjour,