Notes et procédures spécifiques V10.0
#####################################

.. caution:: Veuillez appliquer les procédures spécifiques à chacune des versions précédentes en fonction de la version de départ selon la suite suivante: V8.1 -> V9.0 -> V9.1 -> V10.0

Adaptation des sources de déploiement ansible
=============================================

Réorganisation du stockage workspace par tenant et seuils de saturation
------------------------------------------------------------------------

Le composant ``workspace-collect`` organise désormais ses fichiers sous un répertoire propre à chaque tenant, ce qui permet de refuser les versements du module de collecte lorsque le stockage approche de la saturation. Le composant ``workspace`` conserve son organisation historique.

.. caution:: Assurez-vous qu'il n'y ait aucune opérations en cours ou en pause avant de procéder à la montée de version. En effet, après la montée de version, ces opérations ne pourront pas être reprise suite à la modification de leur chemin d'accès sur les workspaces.

.. note:: L'organisation par tenant et les contrôles de saturation sont imposés : ``workspace-collect`` stocke toujours ses fichiers par tenant, ``workspace`` conserve toujours son organisation historique. Ces valeurs ne sont pas configurables.

L'organisation du stockage, la configuration des seuils et les précautions d'usage sont décrites dans la documentation d'exploitation, au chapitre :ref:`workspace_storage_thresholds`.

Validation de la chaîne de confiance des certificats TSA
---------------------------------------------------------

Le composant worker peut désormais valider la chaîne de confiance des certificats TSA utilisés lors de la vérification des preuves d'horodatage. Cette validation est **désactivée par défaut** ; aucune action n'est requise lors de la montée de version si vous ne souhaitez pas l'activer.

Pour activer cette validation, positionner la variable suivante (par exemple dans le bloc ``worker`` du fichier ``environments/group_vars/all/advanced/vitam_vars.yml``) :

.. code-block:: yaml

    vitam:
      worker:
        timestamp_truststore_enabled: true

..

Avant le déploiement, déposez ensuite les certificats TSA de confiance dans le répertoire ``environments/certs/timestamping/trusted``, sous forme de fichiers portant l'extension ``.crt`` (encodés indifféremment en DER ou en PEM), puis exécutez :

.. code-block:: bash

    ./generate_stores.sh

..

.. caution:: Le répertoire ``environments/certs/timestamping/trusted`` doit contenir l'ensemble des certificats TSA utilisés au fil du temps : les certificats actuellement en service, mais également les anciens certificats si des renouvellements ont eu lieu. Les preuves d'horodatage déjà produites ont été signées avec les anciens certificats ; leur vérification échouerait si ceux-ci étaient absents du truststore.

Cette commande génère le fichier ``environments/keystores/timestamping/truststore_timestamping.p12`` en utilisant le mot de passe ``truststores.timestamping`` défini dans ``environments/group_vars/all/main/vault-keystores.yml``.

Lorsque la validation est activée, le déploiement du composant worker échoue en l'absence de ce truststore. Après le déploiement, une preuve d'horodatage dont le certificat TSA ne peut pas être rattaché à l'un des certificats de confiance est rejetée lors de sa vérification.

.. TODO : À intégrer dans la procédure de montée de version V10.0 (étape « Lancement du master playbook vitam »).

Gestion du démarrage des Jobs Vitam lors d'une montée de version
----------------------------------------------------------------

Les `Jobs Vitam` sont démarrés automatiquement à la fin du master playbook ``ansible-vitam/vitam.yml``. Ce démarrage est désormais conditionné par l'extra var ``prevent_scheduling_start``, positionnée à ``false`` par défaut.

Lors d'une montée de version, il **faut impérativement** passer ``prevent_scheduling_start=true`` au lancement du master playbook, afin que les `Jobs Vitam` ne se relancent pas alors que la post-migration n'est pas terminée :

.. code-block:: bash

    ansible-playbook -i environments/<inventaire> ansible-vitam/vitam.yml --ask-vault-pass -e prevent_scheduling_start=true

..

Une fois les procédures de post-migration finalisées, les `Jobs Vitam` devront être démarrés explicitement via le playbook d'exploitation :

.. code-block:: bash

    ansible-playbook -i environments/<inventaire> ansible-vitam-exploitation/start_vitam_scheduling.yml --ask-vault-pass

..
