
.. _environment_cleaning:

Nettoyage d'un environnement
############################

.. warning :: La procédure suivante ne doit être appliquée QUE sur un environnement de recette et NE DOIT PAS être utilisée sur un environnement de production.

Un playbook ansible de nettoyage d'un environnement est fourni et permet de purger un environnement afin de le réinitialiser à son état presque initial.


Le nettoyage d'un environnement s'effectue selon la procédure suivante :

* Exécuter la commande suivante afin de nettoyer l'environnement (offres de stockage, workspace et bases de données) :

    .. code-block:: bash

        ansible-playbook ansible-vitam-exploitation/cleaning.yml -i environments/hosts.<environnement> --ask-vault-pass


En détails, le nettoyage d'un environnement va exécuter la liste des actions suivantes :

1. Arrêt des modules externes, afin que Vitam ne puisse plus accepter de demandes provenant de l'extérieur.
2. Purge des collections MongoDB :

  * ``LogbookLifeCycleObjectGroup``
  * ``LogbookLifeCycleObjectGroupInProcess``
  * ``LogbookLifeCycleUnit``
  * ``LogbookLifeCycleUnitInProcess``
  * ``LogbookOperation``
  * ``AccessionRegisterDetail``
  * ``AccessionRegisterSummary``
  * ``AccessionRegisterSymbolic``
  * ``ObjectGroup``
  * ``Unit``
  * ``EliminationActionObjectGroup``
  * ``EliminationActionUnit``
  * ``PreservationReport``

3. Réindexation des collections à indexer et purgées en phase 2 : le but étant d'obtenir en fin de traitement des indexes vides (ne contenant aucun document).

  - ``LogbookOperation``, ``ObjectGroup`` & ``Unit`` : une réindexation sera effectuée pour chaque tenant configuré (ex : unit_0_20190130_104530, unit_1_20190130_104540, etc...).
  - ``AccessionRegisterDetail``, ``AccessionRegisterSummary``, ``AccessionRegisterSymbolic`` : 3 nouveaux indexes seront créés au total pour les 3 collections (ex : ``accessionregistersymbolic_20190121_133507``, ``accessionregistersummary_20190121_133503`` & ``accessionregisterdetail_20190121_133505``)

4. Nettoyage des offres de stockage. Selon la configuration de l'environnement, le script est en charge de nettoyer chaque offre de stockage configurée :

  - Pour chaque tenant configuré dans Vitam, le script va supprimer tous les sous-containers ainsi que leurs contenus exceptés : "backup" (contenant les référentiels intégrés dans Vitam) et "rules".
  - Pour l'offre File-System, chaque sous-containers supprimé et vidé de son contenu, sera recréé à vide (ex : ``int_0_accessionregisterdetail``)

5. Nettoyage du `workspace` : le contenu des objets contenus dans le workspace sera purgé également.

.. warning:: Pour le moment, seules les offres de stockage S3 et File-System sont prises en compte dans la purge des offres de stockage.

Sur AlmaLinux 10, la préparation de la purge Swift utilise ``epel-release`` puis les RPM ``python3-swiftclient`` et ``python3-swiftclient+keystone``, avec CRB activé pour leur installation. Les tâches avec et sans proxy sont conservées. Les mises à jour pip des bibliothèques système sont ignorées sur EL10, car les dépendances du client Swift sont gérées par RPM.

Ces clients sont disponibles dans EPEL 10.2. Leur installation et la commande ``swift --version`` ont été vérifiées sur AlmaLinux 10.2 (client 4.10.0) ; l'authentification et la purge d'une offre de recette restent à valider. Les autres plateformes conservent leur préparation existante.

.. warning:: Cette opération provoque une indisponibilité complète de :term:`VITAM`


Etat des lieux après purge
==========================

Après le passage du script, l'environnement est purgé :

* Les référentiels sont toujours présents (Contrats d'accès, contrats d'entrée, rêgles de gestion, etc...).
* L'environnement est disponible et utilisable : les modules externes sont accessibles (IngestExternal et AccessExternal).
* Les offres de stockage sont vidées, à l'exception des backups des référentiels.
* La cohérence entre MongoDB et ElasticSearch est assurée. La plupart des collections sont vidées, et les indexes E/S associés ne contiennent aucun document.
* Le workspace est purgé, aucune opération n'est en cours et ne peut être relancée.

Limitations
===========

Le fait de purger les journaux et non les référentiels provoquera une incohérence de la plate-forme vis-à-vis de la norme **NFZ-42020** (suppression des logs d'imports de référentiels, mais présence de ceux-ci).
