DJANGO_SETTINGS_MODULE n'est plus modifiable sans relancer uwsgi #10

Open
opened 3 years ago by vincent.adolphe · 0 comments
Owner

La chaine que nous utilisons en production (settings/__init__.py) pour définir DJANGO_SETTINGS_MODULE agit comme un aimant:

  • une fois que cette variable a une valeur, elle ne changera plus:
  1. lancement de uwsgi, il n'y a pas de variables d'environnement définit
  2. <APP>/wsgi.py appelle <APP>/settings/__init__.py
  3. et donne à variable python DJANGO_SETTINGS_MODULE la valeur de la variable d'environnement du même nom.
  4. Sauf si elle n'existe pas, auquel cas il construit cette varialbe en lisant config.env
  5. <APP>/wsgi.py utilise la variable python DJANGO_SETTINGS_MODULE pour definir la variable d'environnement du meme nom.

Bref, on ne change pas DJANGO_SETTINGS_MODULE si la variable d'environnement est déjà définit, ce qui me semble correct, mais dans le même temps on positionne aussi cette variable. Et comme uwsgi est assez conservateur cette variable va rester en mémoire même si on fait un touch <APP>/wsgi.py.

Un touch ou un double renommage (orig -> orig.nop -> orig) du fichier de config dans /etc/uwsgi-emperor/vassals) permet de repartir sur un environnement vierge et est moins bourin qu'un systemctl restart uwsgi....

Le cas problématique reste rare, puisque nous avons 2 valeurs possibles pour cette variable avec une variante "production" et une variante "development".

Mais admettons que la valeur de DJANGO_SETTINGS_MODULE doive changer (mettons un gros refactoring comme dans gABy) le bug est difficile à voir.

Je ne sais pas comment faire pour résoudre ça, pour le moment j'imagine quelque-chose comme ça:

  • on garde la même approche, c'est a dire qu'on s'aligne sur les variables d'environnement en priorité
  • mais avant de lire les variables d'environnement, si on détecte un drapeau (sous forme d'une variable d'environnement ?) signifiant "les variables d'env son sous notre responsabilité car c'est nous qui les avons créé", on vide ces variables d'environnement d'abord (y compris le drapeau).
  • ensuite quand ou on définit des variables d'environnement (wsgi.py par exemple), on positionne ce drapeau.

Il faudrait revoir ça a tête reposée (il y a peut être qqchose à faire avec la variable READ_CONFIG_FILE ?)

La chaine que nous utilisons en production (`settings/__init__.py`) pour définir `DJANGO_SETTINGS_MODULE` agit comme un aimant: - une fois que cette variable a une valeur, elle ne changera plus: 1. lancement de uwsgi, il n'y a pas de variables d'environnement définit 1. `<APP>/wsgi.py` appelle `<APP>/settings/__init__.py` 1. et donne à variable python `DJANGO_SETTINGS_MODULE` la valeur de la variable d'environnement du même nom. 1. Sauf si elle n'existe pas, auquel cas il construit cette varialbe en lisant `config.env` 1. `<APP>/wsgi.py` utilise la variable python `DJANGO_SETTINGS_MODULE` pour definir la variable d'environnement du meme nom. Bref, on ne change pas `DJANGO_SETTINGS_MODULE` si la variable d'environnement est déjà définit, ce qui me semble correct, mais dans le même temps on positionne aussi cette variable. Et comme `uwsgi` est assez conservateur cette variable va rester en mémoire même si on fait un `touch <APP>/wsgi.py`. Un `touch` ou un double renommage (`orig` -> `orig.nop` -> `orig`) du fichier de config dans `/etc/uwsgi-emperor/vassals`) permet de repartir sur un environnement vierge et est moins bourin qu'un `systemctl restart uwsgi...`. Le cas problématique reste rare, puisque nous avons 2 valeurs possibles pour cette variable avec une variante "production" et une variante "development". Mais admettons que la valeur de `DJANGO_SETTINGS_MODULE` doive changer (mettons un gros refactoring comme dans `gABy`) le bug est difficile à voir. Je ne sais pas comment faire pour résoudre ça, pour le moment j'imagine quelque-chose comme ça: - on garde la même approche, c'est a dire qu'on s'aligne sur les variables d'environnement en priorité - mais avant de lire les variables d'environnement, si on détecte un drapeau (sous forme d'une variable d'environnement ?) signifiant "les variables d'env son sous notre responsabilité car c'est nous qui les avons créé", on vide ces variables d'environnement d'abord (y compris le drapeau). - ensuite quand ou on définit des variables d'environnement (`wsgi.py` par exemple), on positionne ce drapeau. Il faudrait revoir ça a tête reposée (il y a peut être qqchose à faire avec la variable `READ_CONFIG_FILE` ?)
Sign in to join this conversation.
No Label
No Milestone
No Assignees
1 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.
Map all the world