Produits Entr'ouvert » w.c.s.

(Cette fois vraiment dans w.c.s.)

Il y a déjà du code différent (dans hobo.contrib.ozwillo) pour appeler le delete_tenant de w.c.s.; plutôt qu'ajouter du code ici, j'appellerais la commande backup qui existe déjà pour produire un .tar.gz, qu'il est évidemment possible d'étendre pour inclure également un dump sql dedans.

Mais je ne mêlerais pas archivage et suppression dans la même commande.

Pour reprendre ce que disait Fred (et vérifié que j'ai bien compris): améliorer la commande backup pour ajouter le dump de la base (actuellement on ne dump que les fichiers du tenant).

Jean-Baptiste Jaillet a écrit :

Hop. J'ai essayé de faire les tests mais je n'ai pas su faire avec la commande (et il n'y avait pas de test précédemment pour backup). Comme tout le code est dans la méthode execute, contrairement aux tests que j'ai pu voir sur les autres commandes (si c'est faisable je veux bien une astuce). Ou alors il faut déplacer le code dans une méthode qui est appelée dans execute (comme delete_tenant par exemple).

Comme tu as déjà trouvé la solution, je te propose de l'auto-accepter et de la développer.

« C'est curieux, chez les marins, ce besoin de faire des phrases ... »

Sinon j'ai testé sur la dev de sictiam et la preprod (pour avoir connexion locale et distante) sur l'instance sospel et tout marche bien. J'ai laissé le fonctionnement sur nom de fichier d'archive en option et je me base là dessus pour faire le dump et le zip (je récupère le dossier parent).

Bon c'est bizarre, dans un cas ça fait un tarball que ça pose soit dans sub_options.filename, soit dans <tenant>/backups/<hostname>-backup-<date + ou - ISO zarbi>.tar.gz et dans l'autre cas ça crée un zip dans basedir(sub_options.filename)/<hostname>-<backup>-<data + ou - ISO zarbi>.zip ou dans <tenant>/backups/<idem>.zip.

• avoir un paramètre --destination et pas --filename, toujours créer un zip, nommé le zip "<application>__<hostname>__<date iso>.zip"
• utiliser l'extension .sql pour le dump postgresql
• structurer tout ça,

en gros les mêmes remarques que sur #17725

Si on éloigne backup du comportement actuel, il faut faire suivre la commande restore.

Frédéric Péters a écrit :

Si on éloigne backup du comportement actuel, il faut faire suivre la commande restore.

Ça me parait un bon exercice.

Hum ok j'ai tout refait pour wcs, et je regarde restore. On veut juste changer les options, ou du coup avoir un restore qui peut recupérer un zip et reconstruire la base etc ? (ou il faut que la base existe ?).
Si oui il me semble mieux de faire un autre ticket que je puisse valider la partie backup et je fais le patch pour restore dans l'autre ticket.
(dès que j'ai fini les tests je mets le patch, dans la soirée).

Je me suis auto répondu pour restore : https://dev.entrouvert.org/issues/17790. J'ai mis quelques questions de départ et suis preneur de conseils pour le départ.

    os.mkdir('/tmp/test')

Tu ne peux pas toucher comme ça aux /tmp des gens. tempfile.mkdtemp fait le job correct manuellement mais tu peux aussi regarder à https://docs.pytest.org/en/latest/tmpdir.html#the-tmpdir-factory-fixture pour quelque chose intégré à pytest.

    if not any(z for z in os.listdir('/tmp/test') if '.zip' in z):
        assert False

Idiomatiquement, on ferait plutôt, en Python et particulièrement dans w.c.s. : assert [x for x in os.listdir('/tmp/test') if x.endswith('.zip')]

datetime.datetime.now().date() c'est datetime.date.today().

Pas fan du tar.gz dans un zip dans un cas et pas l'autre; et comme pas fan de l'idée d'un tar.gz dans un zip, pourquoi ne pas tout taper, répertoires de w.c.s. et dump de la db dans le même fichier (peu importe que ça soit zip ou tar.gz).

            subprocess.check_call(['pg_dump', '-Oc', '-h', db_host,
                                   '-U', db_user, '-p', db_port,
                                   '-w', '-f', dump_path, '-d', db_name])

Dans la commande qui supprime un tenant de w.c.s., on peut se trouver à créer un schéma dans la db; si jamais ensuite la db est réutilisée, le dump ici il va également prendre ces "vieilles" infos, je préciserais --schema=public.

Frédéric Péters a écrit :

Pas fan du tar.gz dans un zip dans un cas et pas l'autre; et comme pas fan de l'idée d'un tar.gz dans un zip, pourquoi ne pas tout taper, répertoires de w.c.s. et dump de la db dans le même fichier (peu importe que ça soit zip ou tar.gz).

L'avantage que je voyais au tar.gz c'est le support des liens symboliques qui sont notamment utilisés par storage.py, mais qu'on pourrait avoir autrement aussi. Alors peut-être qu'on devrait plutôt faire un tar.gz tout court et zapper l

Personne n'utilise ou n'utilisera cette commande, qu'il faudrait sinon porter en management command, je serais plutôt pour la supprimer.

De fait c'est utilisé au sictiam pour le deprovisionning (dans sa version actuelle sans backup SQL) donc la question est plutôt est-ce qu'on veut développer un vrai deprovisionning dans hobo, ou plus vraisemblable on statue que ça n'arrive qu'un fois par décade et donc c'est très bien à la main.