Produits Entr'ouvert » Hobo

J'aurais tendance à dire que non incompréhesion de fond, et je m'explique, le recipe, c'est juste un raccourci pour ne pas avoir à passer par l'UI pour un déploiement, pour ajouter un service, ajouter un deuxième, etc. définir le thème, etc.

Mais tout ce que ça crée est déjà présent dans les différents modèles de l'application, il n'y a aucune information supplémentaire portée par le recipe; en soit ça aurait pu juste être le code d'export/import d'un hobo.

il n'y a aucune information supplémentaire portée par le recipe; en soit ça aurait pu juste être le code d'export/import d'un hobo.

L'information supplémentaire c'est un groupe de briques à déployer avec des paramètres (nom, squelette, template d'url), j'aimerais pouvoir formaliser cela d'une façon ou une autre. Sur notre cluster de test on aurait par exemple une recette générique pour déployer des "Publik complets" avec des URL standardisées .test.entrouvert.org; idem pour Signal Publik sur le cluster de production.

On pourrait stocker cela dans des fichiers sur les différents clusters dans /var/lib/hobo/recipes, mais cela impliquerait des procédures de mise-à-jour de ces fichiers via scp. Il me semble qu'un objet stocké en db est pertinent.

L'information supplémentaire c'est un groupe de briques à déployer avec des paramètres (nom, squelette, template d'url) (...)

Mon propos c'est qu'un hobo c'est une série de briques déployées (/en cours de déploiement), l'info "tiens initialement c'est avec ce fichier recipe que ça a été déployé" ne devrait pas être utile.

On pourrait stocker cela dans des fichiers sur les différents clusters dans /var/lib/hobo/recipes, mais cela impliquerait des procédures de mise-à-jour de ces fichiers via scp. Il me semble qu'un objet stocké en db est pertinent.

(sur le propos même je ne suis pas d'accord, on gère mille fois mieux la maintenance de fichiers (on a la possibilité de puppet, de paquets .deb, des tas d'outils en ligne de commande) qu'un blob multiligne posé en base de données).

_~~

Je notais l'importance d'élaborer un plan, c'est nécessaire avant de se lancer dans un truc ici. (parce que le truc pertinent que je peux voir ici c'est la construction d'un "méta-hobo", qui est aux déploiements de plateformes complètes ce qu'hobo est au déploiement d'un service, mais ça ne s'établit pas sans être vraiment sûr de la direction).