Bug #7205
problème de "lock" pendant un déploiement (crash agent deploiement authentic2)
0%
Description
- authentic2-multitenant tout neuf, aucun tenant
- création d'un tenant hobo
- ajout d'un tenant authentic2 via hobo
crash de l'agent immédiat, il est clair que le migrate n'a pas eu le temps de s'exécuter lors de la création du tenant authentic2 (ça prend 10 secondes quand c'est fait manuellement)
La trace dans /var/log/hobo-agent/stderr.log
[2015-05-12 00:10:51,729: INFO/MainProcess] Task hobo-deploy[ddb7cfdc-de91-45db-8350-4f29c81807da] succeeded in 0.530074137001s: None
[2015-05-12 00:11:01,651: INFO/MainProcess] Received task: hobo-deploy[15dfcc00-9c58-45a1-8460-7e134777b39f] expires:[2015-05-11 22:13:01.641412+00:00]
[2015-05-12 00:11:12,047: INFO/MainProcess] Received task: hobo-deploy[375389fd-859e-4a01-8c1a-f8614dfc6765] expires:[2015-05-11 22:13:12.037663+00:00]
Traceback (most recent call last):
File "/usr/lib/authentic2/manage.py", line 20, in <module>
execute_from_command_line(sys.argv[:1] + argv)
File "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py", line 385, in execute_from_command_line
utility.execute()
File "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py", line 377, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/usr/lib/python2.7/dist-packages/django/core/management/base.py", line 288, in run_from_argv
self.execute(*args, **options.__dict__)
File "/usr/lib/python2.7/dist-packages/django/core/management/base.py", line 338, in execute
output = self.handle(*args, **options)
File "/usr/lib/python2.7/dist-packages/hobo/agent/common/management/commands/hobo_deploy.py", line 56, in handle
self.deploy_specifics(hobo_environment, tenant)
File "/usr/lib/python2.7/dist-packages/hobo/agent/authentic2/management/commands/hobo_deploy.py", line 60, in deploy_specifics
username=user_dict.get('username'))
File "/usr/lib/python2.7/dist-packages/django/db/models/manager.py", line 92, in manager_method
return getattr(self.get_queryset(), name)(*args, **kwargs)
File "/usr/lib/python2.7/dist-packages/django/db/models/query.py", line 422, in get_or_create
return self.get(**lookup), False
File "/usr/lib/python2.7/dist-packages/django/db/models/query.py", line 351, in get
num = len(clone)
File "/usr/lib/python2.7/dist-packages/django/db/models/query.py", line 122, in __len__
self._fetch_all()
File "/usr/lib/python2.7/dist-packages/django/db/models/query.py", line 966, in _fetch_all
self._result_cache = list(self.iterator())
File "/usr/lib/python2.7/dist-packages/django/db/models/query.py", line 265, in iterator
for row in compiler.results_iter():
File "/usr/lib/python2.7/dist-packages/django/db/models/sql/compiler.py", line 700, in results_iter
for rows in self.execute_sql(MULTI):
File "/usr/lib/python2.7/dist-packages/django/db/models/sql/compiler.py", line 786, in execute_sql
cursor.execute(sql, params)
File "/usr/lib/python2.7/dist-packages/django/db/backends/utils.py", line 81, in execute
return super(CursorDebugWrapper, self).execute(sql, params)
File "/usr/lib/python2.7/dist-packages/django/db/backends/utils.py", line 65, in execute
return self.cursor.execute(sql, params)
File "/usr/lib/python2.7/dist-packages/django/db/utils.py", line 94, in __exit__
six.reraise(dj_exc_type, dj_exc_value, traceback)
File "/usr/lib/python2.7/dist-packages/django/db/backends/utils.py", line 65, in execute
return self.cursor.execute(sql, params)
django.db.utils.ProgrammingError: relation "custom_user_user" does not exist
LINE 1: ...is_active", "custom_user_user"."date_joined" FROM "custom_us...
^
[2015-05-12 00:10:51,729: INFO/MainProcess] Task hobo-deploy[ddb7cfdc-de91-45db-8350-4f29c81807da] succeeded in 0.530074137001s: None
Fichiers
Demandes liées
Révisions associées
Historique
Mis à jour par Thomas Noël il y a presque 9 ans
En reprenant une nouvelle fois à zéro, il y a deux messages hobo-deploy envoyés à quelques dixièmes de secondes, ce qui lance deux déployeurs d'authentic. Le premier a le temps de créer un début de tenant, le second pense que c'est déjà fait et tente de continuer en créant l'utilisateur, plantage...
[2015-05-12 00:22:05,274: INFO/MainProcess] Received task: hobo-deploy[8620a430-05fc-4a6f-afb2-427e5d43ed14] expires:[2015-05-11 22:24:05.263836+00:00]
[2015-05-12 00:22:05,970: INFO/MainProcess] Received task: hobo-deploy[ba693edb-29ad-4eea-ba5c-e242cecbfd0d] expires:[2015-05-11 22:24:05.960308+00:00]
Generating a 1024 bit RSA private key
........++++++
........................................................++++++
unable to write 'random state'
writing new private key to '/var/lib/authentic2-multitenant/tenants/authentic.imio.entrouvert.org/saml.key'
-----
Traceback (most recent call last):
File "/usr/lib/authentic2/manage.py", line 20, in <module>
execute_from_command_line(sys.argv[:1] + argv)
(...)
Mis à jour par Thomas Noël il y a presque 9 ans
Idée 1 : ajouter lock lors de la création d'un tenant
Mis à jour par Frédéric Péters il y a presque 9 ans
J'en étais aussi sur cette idée, sur la lecture de la description du ticket. Sans nécessairement aller sur du "vrai" lock; mais que le premier truc fait après le mkdir() soit l'ajout d'un fichier disant "pas encore prêt", et qu'il y ait attente sur un tenant.is_ready() dans le hobo_deploy (qui peut être aussi sommaure que "while os.path.exists(...): sleep(1)"). Ou quitter directement si le tenant n'est pas prêt, en se disant qu'il y aura bien un autre hobo_deploy appelé derrière.
Mis à jour par Thomas Noël il y a presque 9 ans
Je suis en train de simplement tester ceci, bête et méchant, ce qui me semble bien pour un "lock" qui n'en sera jamais complétement un:
- if not os.path.exists(tenant_dir):
- os.mkdir(tenant_dir, 0755)
+ if os.path.exists(tenant_dir):
+ if verbosity >= 1:
+ print self.style.ERROR("=== Tenant %s already exists" % hostname)
+ continue
+ os.mkdir(tenant_dir, 0755)
Mis à jour par Thomas Noël il y a presque 9 ans
Marche pas, c'est normal dans hobo_deploy on considère que le tenant est crée dès que TenantMiddleware.get_tenant_by_hostname(domain) renvoie quelque chose, et celui-ci dit "ok" si le répertoire existe, ce qui est faut.
Et donc, la prochaine fois, je relirai mieux les commentaires de Frédéric.
Mis à jour par Frédéric Péters il y a presque 9 ans
Ce matin je me dis que le lock, il pourrait être autour de l'hobo_deploy en entier, pas au niveau fin du create_tenant.
En gros :
--- a/hobo/agent/worker/services.py
+++ b/hobo/agent/worker/services.py
@@ -107,4 +107,5 @@ def deploy(environment):
if service_obj.check_timestamp(hobo_timestamp):
logger.debug('skipping uptodate site: %r', service_obj)
continue
- service_obj.execute(environment)
+ with lock(service):
+ service_obj.execute(environment)
Mis à jour par Thomas Noël il y a presque 9 ans
- Sujet changé de agent deploiement authentic2: relation "custom_user_user" does not exist à problème de "lock" pendant un déploiement (crash agent deploiement authentic2)
- Assigné à mis à Thomas Noël
- Priorité changé de Normal à Haut
Mis à jour par Serghei Mihai (congés, retour 15/05) il y a presque 9 ans
- Fichier 0001-create_tenant-lock-while-tenant-creation-in-progress.patch 0001-create_tenant-lock-while-tenant-creation-in-progress.patch ajouté
- Patch proposed changé de Non à Oui
Proposition de patch après une réflexion commune avec Thomas
Mis à jour par Frédéric Péters il y a presque 9 ans
- Patch proposed changé de Oui à Non
Comme je le notais plus haut il me semble que faire ça au niveau du create_tenant protège trop peu, il reste un temps conséquent (notamment le temps de générer les clés) entre l'appel au create_tenant et la mise en place du hobo.json (qui contient le timestamp et qui éviterait un second appel). Et donc, je pense vraiment que ma proposition du commentaire 7 est à suivre.
Mis à jour par Thomas Noël il y a presque 9 ans
- get_tenant_by_hostname déclenche un TenantNotFound tant que celui-ci n'est pas prêt (lors du migrate initial qui prend plusieurs secondes)
- create_tenant déclenche aussi une erreur s'il est rappelé alors qu'un autre create_tenant n'est pas encore terminé
En conséquence, si un hobo_deploy est appelé pendant que le tenant est en cours de création (et c'est long), il y aura erreur.
On peut aussi ajouter un lock plus général dans hobo_deploy, mais je suis quand même pour ce patch dans hobo.multitenant.
Mis à jour par Frédéric Péters il y a presque 9 ans
- Assigné à changé de Thomas Noël à Serghei Mihai (congés, retour 15/05)
Plus général ou plus spécifique, oui, je suis d'accord qu'il ne peut pas y avoir plusieurs create_tenant exécutés en parallèle pour le même tenant, mais tout autant, il ne peut pas y avoir plusieurs hobo_deploy (qui peuvent également être longs, avec la génération de clés), j'ajouterais donc également un lock au hobo_deploy.
Concernant le patch déjà présent, en cas d'erreur le répertoire temporaire ne devrait à mon avis pas être laissé en place.
Mis à jour par Serghei Mihai (congés, retour 15/05) il y a presque 9 ans
- Fichier 0001-create_tenant-lock-while-tenant-creation-in-progress.patch 0001-create_tenant-lock-while-tenant-creation-in-progress.patch ajouté
- Patch proposed changé de Non à Oui
et afficher l'erreur
Mis à jour par Thomas Noël il y a presque 9 ans
- les
if not os.path.exists(path):inutiles - on peut créer ces sous-répertoires uniquement après la création du schéma (sauf try/except)
Mis à jour par Serghei Mihai (congés, retour 15/05) il y a presque 9 ans
- Statut changé de Nouveau à En cours
d'accord
Mis à jour par Thomas Noël il y a presque 9 ans
- Assigné à changé de Serghei Mihai (congés, retour 15/05) à Thomas Noël
Mis à jour par Thomas Noël il y a presque 9 ans
Mis à jour par Serghei Mihai (congés, retour 15/05) il y a presque 9 ans
Oops, j'avais oublié d'attacher le patch dans mon dernier commentaire.
Ack
Mis à jour par Thomas Noël il y a presque 9 ans
- Statut changé de En cours à Résolu (à déployer)
commit 23abcff2dd08546b637dce0113709c7e169025be
Author: Serghei Mihai <smihai@entrouvert.com>
Date: Mon Jun 8 19:49:19 2015 +0200
create_tenant: lock while tenant creation in progress (#7205)
Mis à jour par Thomas Noël il y a presque 9 ans
- Lié à Bug #7534: ajouter un lock sur hobo_deploy ajouté
Mis à jour par Benjamin Dauvergne il y a plus de 8 ans
- Statut changé de Résolu (à déployer) à Fermé
create_tenant: lock while tenant creation in progress (#7205)