Fourniture d'un dump de prod à des fins de tests : quelles informations dégager?

Hello les agrumes,

J'ai dans l'idée de fournir à qui veut un dump de prod à des fins de test pour qui veut - parce que bosser avec des données quasiment vides, c'est pas toujours pratique. Et bien évidemment je compte dégager les données personnelles.

Voici ce que je pense faire par rapport à un dump "brut" de prod :

• Anonymisation de tous les emails
• Anonymisation de toutes les adresses IP
• Utilisation d'un même mot de passe pour tous les utilisateurs (un truc du genre "password")
• Remplacer tous les titres et les contenus des MP par du faux texte
• Remplacer tous les titres et les contenus des forums privés par du faux texte

J'ai hésité à dégager les MP, sauf que si on a environ 36 000 posts dans 1930 topics, on a aussi 22 000 MP dans 3100 discussions privées… en terme d'impact sur la base, c'est pas du tout négligeable !

Il faudrait vider les galeries car sinon Django va grincer. Je crois aussi que les tutoriels et les articles sont à enlever, à moins que tu fournisses une archive des fichiers Markdown ?

L'inconvénient que je vois, c'est qu'on saurait qui a un MP avec qui - sans savoir à quel sujet.

Le mieux serait aussi d'anonymiser les pseudos (en en générant des faux aléatoirement).

Penser aussi à virer les articles et tutoriels en brouillons ainsi qu'un partie des alertes.

Bonne idee, mais je me demande en quoi ça serait différent de python manage.py load_fixtures sise=high

Basiquement, deux choses :

1. La fonctionnalité dont tu parles n'est pas documentée. En tous cas on en parle pas dans la page ad hoc de la doc et la recherche ne dit rien. J'avais oublié qu'elle existait et ne l'ai pas retrouvée.
2. Si j'en crois le code, le paramètre size=high donne une base de 3, donc 30 utilisateurs etc. C'est très loin des données réelles, en nombre et en proportions.

Si ces fixtures peuvent être pratiques dans bien des cas, il en est d'autres (exemples : tests des API, tous les travaux d'optimisation en cours) qui nécessitent des données réalistes (à défaut d'être réelles).

Ce qui serait bien cool, c'est que j'ai deux/trois archives de tutos pour tester la zep 12 sur des données réelles. Je dois encore avoir une copie d'arduino qui est vraiment un cas pathologique mais j'aimerai tester sur d'autres.

Justement, je me demande ce qui serait plus efficace :

1. Documenter le fonctionnalité, en sachant qu'actuellement lancer python manage.py load_fixtures module=member size=high plusieurs fois permet de rajouter une batterie d'utilisateurs par dessus l'existant. Et éventuellement rajouter une size avec un facteur 100 si besoin.
2. Fournir un dump de la prod

La deuxième solution (si j'en crois le premier post) est quand même très couteuse et pas trop flexible pour les raisons suivantes :

• il faut créer le dump à chaque modification du modèle de donnée (quid des différences de version entre la dev et la prod ?)
• anonymiser le contenu (et donc se poser la question de savoir quoi anonymiser)
• enlever certaines informations (comme les mps)
• mettre a dispos les images de la prod (sans les images, les tutoriels n'ont pas beaucoup de valeur),
• le mettre à disposition tout ceci sur un serveur
• les données ne seront dispo que pour Mysql
• documenter la procédure d'exploitation de ces données (parce que du coup ça ne sera plus de la vrai prod)
• la procédure ne me semble pas Open (car il faut contacter à chaque fois quelqu'un pour avoir les bonnes informations, avec les délais de réponses et la perte de motivation qui peuvent s'en suivre)

Donc a vue de nez, j'ai du mal a voir l'intérêt, mais si tu veux mettre ça en place et le maintenir ça sera toujours mieux que rien

Ben pourquoi pas, si on rétabli les contraintes pour que l'on puisse générer quelque chose de crédible.

Par contre il me semble avoir lu que rien qu'une génération de fixtures de taille "high" était déjà très longue. Est-ce raisonnable de faire un facteur 60 dessus ?

Je sais pas comment je dois le prendre ca… (mais je te refais un dump quand tu veux si besoin)

Par contre il me semble avoir lu que rien qu'une génération de fixtures de taille "high" était déjà très longue. Est-ce raisonnable de faire un facteur 60 dessus ?

Cay moa (10 minutes pour la generation de base, donc pas high) : https://github.com/zestedesavoir/zds-site/pull/1737#issuecomment-64253672

Je sais pas comment je dois le prendre ca… (mais je te refais un dump quand tu veux si besoin)

bien, en fait c'est juste que notre système atteint vraiment ses limites avec arduino.

Visiblement, ça te prend 10 min en mode normal là ou Travis prend 55 secondes . Je suppose que tu dois pas avoir une machine de compète et que tu était sous SQLite là ou travis tourne avec MySQL.

En terme de ratio, les modules les plus longs sont les tutos (78% du temps), les membres (5% du temps) et les galléries (4.5% du temps).

Donc il y'a toujours moyen de s'en sortir en lançant juste la génération de 60 tutos (size=high) et le reste des modules en mode very-high.