Bug #7550
redéploiement automatique en cas de changement d'un service
0%
Description
- quand on ajoute un service, le temps du déploiement, ses metadonnées ne sont pas disponibles
- et donc le hobo-deploy d'authentic ne déploie par le nouveau SP
- et donc il faut systématiquement "redéployer à la main" quelques secondes après déploiement d'un SP.
On a (ou on aura) le même soucis de "redéployer quand ça change sans que hobo le demande" quand un provider qu'on ne contrôle pas changera ses métadonnées.
Il faudrait donc un système qui surveille régulièrement (chaque 5 min?) les métadonnées de la fédération et lance un message de déploiement en cas de modif.
Alternatives:- quand on déploie un SP, lancer un reploiement quand il devient dispo
- avoir un bouton "redéployer maintenant" sur hobo (actuellement on peut mais c'est bidouille)
- rendre l'agent hobo capable d'informer le serveur hobo (message d'info via celery/amqp, genre "j'ai fini de déployé truc" ou "ce machin a bougé", à réflechir)
Fichiers
Historique
Mis à jour par Frédéric Péters il y a presque 9 ans
À partir du moment où un service est déclaré opérationnel, on pourait simplemnt relancer un déploiement général ?
Mis à jour par Benjamin Dauvergne il y a presque 9 ans
Et si hobo était plus actif (donc faisait des checks réguliers de présence des services pas juste quand on regarde la page) et ne publiait un service qu'une fois celui-ci opérationnel (à chaque fois qu'il devient opérationnel en fait), ne serait-ce pas mieux ?
Les états possibles:
(1) (2) (3) Not-deployed -> operationnal <-> unavailable [ -> Un-deployed ]
- (1) ici on déploie
- (2) ici on devrait envoyer un mail
- (3) ici on devrait retirer le service
Mis à jour par Thomas Noël il y a presque 9 ans
Benjamin Dauvergne a écrit :
Et si hobo était plus actif (donc faisait des checks réguliers de présence des services pas juste quand on regarde la page) (...)
Je pense que oui, mais dans un cadre multi-tenant je ne vois pas encore bien comment faire cela.
Mis à jour par Benjamin Dauvergne il y a presque 9 ans
Bah avec un démon. À noter que si on passer en mode pseudo-thread (gevent&co) on pourrait facilement lancer un thread "cron"; on pourrait ne passer que hobo en pseudo-thread (par sécurité avant de voir si ça marche bien).
Mis à jour par Frédéric Péters il y a plus de 8 ans
- Fichier 0001-agent-deploy-twice-in-case-of-new-services-7550.patch 0001-agent-deploy-twice-in-case-of-new-services-7550.patch ajouté
- Statut changé de Nouveau à En cours
- Patch proposed changé de Non à Oui
Voilà en patch une réponse au problème initial (authentic n'attrapant pas les metadata, parce que service pas encore up); c'est vraiment basique mais ça fait le job et ça permet à mon sens d'avancer. Le truc est simplement, quand un nouveau service est déployé (ce qui est détecté parce qu'il n'existait précédemment pas), un nouveau déploiement général est demandé, bam. (ça pourrait être optimisé de mille façon mais j'aimerais poser cette étape avant de réfléchir à des trucs plus complets ou complexes).
Mis à jour par Thomas Noël il y a plus de 8 ans
Moins simple que je le pensais ; je croyais qu'on pouvait passer par une réponse, afin que le hobo (server) reste le seul émetteur... mais comme on broadcast, ben non, pas de réponse possible.
Donc, c'est un "ack" à mes yeux. Mais je verrais bien une relecture par un tiers.
(a part ça, "cmd_process.returncode != 1" serait sans doute bien remplacé par "cmd_process.returncode == 1" ?)
Mis à jour par Frédéric Péters il y a plus de 8 ans
Tu veux sans doute dire "== 0" à la fin, et la réponse c'est que je teste explicitement sur le "== 1" pour ne pas prendre en compte la situation où la commande échoue pour une autre raison.
Mis à jour par Thomas Noël il y a plus de 8 ans
Oui, je voulais dire ==0 (et je pensais que ça ne devait répondre "ça existe" que dans ce cas, mais c'est pas très important, les autres cas ne devraient pas se produire).
De fait, au niveau du "if exists:" dans hobo_deploy.py, on devrait raiser une exception "SystemError" dans un except: final général.
Mis à jour par Thomas Noël il y a plus de 8 ans
Thomas Noël a écrit :
De fait, au niveau du "if exists:" dans hobo_deploy.py, on devrait raiser une exception "SystemError" dans un except: final général.
Je délire du n'importe quoi. Oubliez-moi pour aujourd'hui.
Mis à jour par Serghei Mihai il y a plus de 8 ans
Pourquoi executer new-site
dans une queue séparée?
Mis à jour par Benjamin Dauvergne il y a plus de 8 ans
Et pourquoi ne pas simplement relancer une tâche deploy depuis deploy ? Je me méfie des boucles mais là on peut en avoir une aussi; deploy -> new-site -> deploy ...
Mis à jour par Frédéric Péters il y a plus de 8 ans
Pourquoi executer new-site dans une queue séparée?
En passant du temps de configuration dans rabbitmq, ça permettrait de limiter le broadcast aux serveurs faisant tourner hobo.
Et pourquoi ne pas simplement relancer une tâche deploy depuis deploy ?
C'était dans l'idée de rester dans un modèle où les deploy() sont lancés depuis le service hobo central mais ça pourrait être changé, je n'ai pas d'attachement particulier à ça.
Mis à jour par Benjamin Dauvergne il y a plus de 8 ans
Bon on a pas mieux que ça et c'est tout ce qu'il manque pour un déploiement Montpellier automatique, donc ack. J'aurai bien pris des tests avec mais c'est pas évident.
Mis à jour par Frédéric Péters il y a plus de 8 ans
Ok, je mettrai à jour le patch et le reproposerai.
Mis à jour par Frédéric Péters il y a environ 7 ans
En multi-publik ça devient encore plus sensible parce qu'il faut aller sur le hobo "parent" pour faire la modif bidon.