Development #41250
Instabilité des tests multitenant en python3
0%
Description
Lancés avec tox par Jenkins, en environnement py3-coverage-multitenant
:
tests_multitenant/test_request_context_filter.py .F [ 34%] […] def test_systemd(settings, tenants, client, journald_handler): root_logger = logging.getLogger() assert len(root_logger.handlers) == 2 journald_handler.addFilter(RequestContextFilter()) for tenant in tenants: with tenant_context(tenant): user = User.objects.create(first_name='John', last_name='Doe', username='john.doe', email='jodn.doe@example.com') user.set_password('john.doe') user.save() user.saml_identifiers.create(name_id='ab' * 16, issuer='https://idp.example.com') for tenant in tenants: settings.ALLOWED_HOSTS.append(tenant.domain_url) with tenant_context(tenant): client.login(username='john.doe', password='john.doe') client.get('/', SERVER_NAME=tenant.domain_url, HTTP_X_FORWARDED_FOR='99.99.99.99, 127.0.0.1') from systemd.journal import Reader import time reader = Reader() reader.seek_realtime(time.time() - 10) records = [l for l in reader if l['MESSAGE'] == 'wat!'] > assert len(records) == 2 E AssertionError: assert 4 == 2 E + where 4 = len([{'APPLICATION': 'fake-agent', 'ARGS': '()', 'CODE_FILE': '/var/lib/jenkins/workspace/hobo-wip_wip_41237-tox-a2-py3/ho... 'ARGS': '()', 'CODE_FILE': '/var/lib/jenkins/workspace/hobo/hobo/agent/test_urls.py', 'CODE_FUNC': 'helloworld', ...}]) tests_multitenant/test_request_context_filter.py:84: AssertionError
C'est ici par exemple.
On se retrouve avec un 'CODE_FILE': '/var/lib/jenkins/workspace/hobo-wip_wip_41237-tox-a2-py3/…' comme s'il n'y avait pas d'isolation entre les jobs hobo et hobo-wip en cas d'exécution simultanée.
Fichiers
Révisions associées
Historique
Mis à jour par Thomas Noël il y a environ 4 ans
Effectivement c'est un test particulier qui joue avec hobo.journal.JournalHandler, il faut certainement creuser ici pour tenter de voir comment isoler cela, car il y a certainement possibilité de mélange quand deux tests tournent.
Mis à jour par Benjamin Dauvergne il y a environ 4 ans
- Fichier 0001-tests-make-provisionning-test-less-instable-41250.patch ajouté
- Tracker changé de Bug à Development
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
Mis à jour par Thomas Noël il y a environ 4 ans
C'est vraiment en rapport avec l'erreur journald ?
Mis à jour par Benjamin Dauvergne il y a environ 4 ans
Non tu as raison; ça correspond à un souci causé par un changement dans authentic corrigé dans #41284 (on avait une écriture du compte au login qui n'existait pas avant, ça changeait le nombre d'appels à notify_agents), oublions, j'ai mélangé.
Mis à jour par Benjamin Dauvergne il y a environ 4 ans
- Fichier
0001-tests-make-provisionning-test-less-instable-41250.patchsupprimé
Mis à jour par Benjamin Dauvergne il y a environ 4 ans
Mis à jour par Benjamin Dauvergne il y a environ 4 ans
Mis à jour par Paul Marillonnet il y a environ 4 ans
- Statut changé de Solution proposée à Solution validée
Ça m'embête un peu que dans ce test systemd on retire l'import à… systemd.
Je verrais bien du mocking un peu plus en profondeur pour ne pas virer cet import qui à mon avis donne du sens au test, mais je n'ai pas le temps de le faire (et peut-être pas les capacités non plus ☺).
Si tu préfères laisser comme ça, je comprends, pousse donc.
Mis à jour par Benjamin Dauvergne il y a environ 4 ans
Paul Marillonnet a écrit :
Ça m'embête un peu que dans ce test systemd on retire l'import à… systemd.
Je verrais bien du mocking un peu plus en profondeur pour ne pas virer cet import qui à mon avis donne du sens au test, mais je n'ai pas le temps de le faire (et peut-être pas les capacités non plus ☺).
Si tu préfères laisser comme ça, je comprends, pousse donc.
Je ne comprends pas bien, le test utilise hobo.journal.JournalHandler qui importe justement systemd, tu préfèrerais un mock de systemd.journal.send ?
PS: ça n'est pas vraiment possible, systemd.journal.send
est une valeur par défaut d'un argument du constructeur de JournalHandler, je ne peux pas le mocker, la valeur mockée ne sera pas prise en compte par le constructeur car elle est copié par valeur dans la définition de JournalHandler.__init__.
Mis à jour par Benjamin Dauvergne il y a environ 4 ans
- Statut changé de Solution validée à Résolu (à déployer)
commit 2b0474a2e91b04a622587207dfee3c15edcc58ce Author: Benjamin Dauvergne <bdauvergne@entrouvert.com> Date: Mon Apr 13 11:47:31 2020 +0200 tests_multitenant: mock journald sender (#41250)
Mis à jour par Paul Marillonnet il y a environ 4 ans
Benjamin Dauvergne a écrit :
Je ne comprends pas bien, le test utilise hobo.journal.JournalHandler qui importe justement systemd, tu préfèrerais un mock de systemd.journal.send ?
PS: ça n'est pas vraiment possible,
systemd.journal.send
est une valeur par défaut d'un argument du constructeur de JournalHandler, je ne peux pas le mocker, la valeur mockée ne sera pas prise en compte par le constructeur car elle est copié par valeur dans la définition de JournalHandler.__init__.
D'ac pas de souci (c'est le Reader
que j'aurais aimé voir conservé, pour être sûr qu'en plus de l'écriture, il n'y a pas non plus d'erreur à la lecture des journaux avec la lib python{,3}-systemd).
Mis à jour par Benjamin Dauvergne il y a environ 4 ans
Paul Marillonnet a écrit :
D'ac pas de souci (c'est le
Reader
que j'aurais aimé voir conservé, pour être sûr qu'en plus de l'écriture, il n'y a pas non plus d'erreur à la lecture des journaux avec la lib python{,3}-systemd).
Ça ne nous concerne plus là, c'était par facilité (finalement pas une bonne idée) que je passais par cette API, mais c'est le problème de python-systemd.
Mis à jour par Frédéric Péters il y a environ 4 ans
- Statut changé de Résolu (à déployer) à Solution déployée
tests_multitenant: mock journald sender (#41250)