La migration d'un Pod v2 vers un Pod v3 a été réalisée de façon différente selon les établissements. Voici 2 procédures différentes qui peuvent vous être utiles selon le contexte et votre environnement.

1ère possibilité : procédure initiale, réalisée par Joshua

Installation sur un nouveau serveur

Pour faire la migration depuis la V2, j'ai (Joshua) fait une installation sur un nouveau serveur. J'ai donc rapatrié les données (hors média) ainsi que la bdd.

$> cd /usr/local/django_projects/
$> tar --exclude='./pod/static' --exclude='./pod/media' -zcvf podv2.tgz ./podv2
$> mysqldump -h bdd.univ.fr -u pod2 -pXXXXXXXXXX pod2 > dumpfile.sql

Pensez a récupérer les scripts de migration des librairies pythons utilisées par pod ($HOME/.local/ sur ubuntu si vous n'utilisez pas de virtual env, sinon ./<votre_virtual_env>) dans une archive tar que vous décompresserez dans votre environnement cible après avoir installé les librairies (pip install)

# Il faut patcher dans le tar la version de python que vous aller utiliser en PODv3
find <path_de_vos_librairies_python> -path "*/migrations/00*.py" -not -name "__init__.py" -exec tar --transform='s|python3.7|python3.9|' -rvf migration.tar {} \;

J'ai rapatrié ces 2 fichiers sur mon nouveau serveur et j'ai déployé les données.

$> cd /usr/local/django_projects
$> tar -xvzf podv2.tgz .
$> mysql -h bdd.univ.fr -u pod2 -pXXXXXXXXXXX  pod3 < dumpfile.sql

→ Ne pas oublier de modifier le fichier de settings_local pour diriger vers la nouvelle BDD

Pour ceux qui utilisaient encore les vidéos interactives :

il faut remonter un environnement virtuel v2 : $> mkvirtualenv --system-site-packages --python=/usr/bin/python3 django_pod2

Ensuite, installer les dépendances qui vont bien : 

$> python3 -m pip install -r requirements.txt

$> pip3 install mysqlclient==2.0.3

Il faut supprimer l'application de la base de données:

$> python manage.py migrate interactive zero

l'application tierce "interactive" n'est plus présente dans le code de Pod3, il faut donc penser à la retirer dans le settings_local (THIRD_PARTY_APPS = ["enrichment", "live"])

J'ai ensuite créé un nouvel environnement virtuel pour pod3

$> mkvirtualenv --system-site-packages --python=/usr/bin/python3 django_pod3

et j'ai récupéré la dernière version de Pod:

(django_pod3) pod@pod3:/usr/local/django_projects/podv3$ git pull origin master

Un MakeFile est maintenant fourni pour simplifier les commandes

(django_pod3) pod@pod3:/usr/local/django_projects/podv3$ cat Makefile

Vous pouvez donc l’utiliser pour finaliser votre installation. Il y a une commande pour tout mettre à jour : $> make upgrade, toutefois, je préfère détailler ici les étapes :

Je commence à installer les lib python :

$> python3 -m pip install -r requirements.txt

Ensuite, je prépare les commandes de mis à jour de la bdd.

tar xvf migration.tar

$> make updatedb

Si vous rencontrez l'erreur ImportError: cannot import name 'FieldDoesNotExist' from 'django.db.models.fields' alors il faut mettre à jour django_select2_forms via la commande

$> pip3 install django_select2_forms --upgrade

Une fois la préparation de la migration effectuée, je peux migrer ma base de données :

$> make migrate

Enfin, si tout est ok, vous pouvez respirer et collecter les fichiers statics pour Pod. Il suffit pour cela de lancer cette commande :

# Si vous êtes dans un environnement contenairisé et qu'il y a des fichiers customs dans le répertoire static
python3 manage.py collectstatic
# Si vous pouvez vous permettre de tout effacer dans static ( python3 manage.py collectstatic --clear )
make statics

Redis :

Dans cette version l'installation d'un serveur Redis pour la gestion du cache est obligatoire.

Voir la partie Installation de Redis de Installation de Pod V3 ou la doc officielle https://redis.io/docs/getting-started/

ElasticSearch :

Si vous changez d'instance ElasticSearch (notamment si vous n'utilisez pas un service ES déporté), pensez à réindexer les contenus avec cette commande :

cd django_projects/podv3
python manage.py index_videos --all

Si l'indexation échoue, jettez un oeil à pod/video_search/commands/index_videos.py si vous voyez une mention de __VIDEOS__ alors il faut la substituer par pod.video.context_processors.get_available_videos

Si après indexation vous n'avez aucune vidéo sur votre site et lors de vos recherches ou que vous avez des videos mais que vous ne pouvez pas les jouer, il se peut que certaines tables ne soient pas migrées, dans mon cas il fallait migrer:

• video_encodingvideo => video_encode_transcript_encodingvideo
• video_encodingaudio => video_encode_transcript_encodingaudio
• video_encodingstep => video_encode_transcript_encodingstep
• video_playlistvideo => video_encode_transcript_playlistvideo
• video_videorendition => video_encode_transcript_videorendition ( attention, cette table a un nouveau field threshold qu'il faut mettre à 0 par défaut)

That's all folks !

2ième possibilité : réalisée par Loïc pour l'université de Montpellier

Contexte

Ayant eu des problèmes avec la 1ère procédure lors de la migration de la version 2 vers la version 3 d'Esup-Pod en février 2023, j'ai fais différemment.

A cette époque, l'architecture a totalement été modifiée avec l'installation de nouveaux serveurs sous Debian 11.x, une rationalisation du nombre de serveurs et l'arrêt de l'architecture de Pod v2.

L'idée de cette procédure est d'installer Pod v3.0.5 sur les différents serveurs, from scratch, sans s'occuper de l'historique puis, une fois que ce Pod v3 vierge est fonctionnel, réaliser les manipulations nécessaires pour récupérer la base de données du Pod v2.

Voici alors les étapes réalisées pour réaliser une migration d'un Pod v2.9.1 vers un Pod v3.0.5.

Étapes de la migration

1. Installation des nouveaux serveurs pour l'architecture Pod v3

Typiquement, dans mon cas, l'architecture repose sur des VMs sous Debian 11.X.

2. Installation d'Esup-pod v3 sur les différents serveurs

En suivant la documentation du projet, j'ai installé Pod 3.0.5 sur les différents serveurs de mon infrastructure.

3. Migration de la base de données

Base Pod v3 vierge

Si vous avez réalisé les étapes précédentes, vous devriez avoir une bd de Pod v3 initialisée avec les données de base.

Supprimer alors les données de toutes les tables SAUF django_migrations.

A ce moment là, nous avons une base de données de Pod v3 vierge.

EN CAS DE PROBLÈME SEULEMENT - POSSIBILITÉ DE REFAIRE CETTE MANIPULATION PLUSIEURS FOIS

Si cela ne marche pas du 1° coup, il est possible de recommencer en repartant de 0 en réalisant les commandes suivantes sur une base totalement vide.

cd /usr/local/django_projects/podv3
workon django_pod3
# Suppression des fichiers de migrations
find . -path "*/migrations/*.py" -not -name "__init__.py" -delete
find . -path "*/migrations/*.pyc" -delete

# Penser également aux flatpages dont les fichiers de migration se trouvent dans le virtualenv
# Dans mon cas, cela revient à supprimer les fichiers de migrations (mais pas __init__.py) dans /home/pod/.virtualenvs/django_pod3/lib/python3.9/site-packages/django/contrib/flatpages/migrations/

make updatedb
make migrate

# Puis vider les données de toutes les tables SAUF django_migrations

A ce moment là, nous avons une base de données de Pod v3 vierge.

Récupération des données de la base Pod v2

J'ai alors récupéré les données de Pod v2 via la procédure suivante, réalisée via PHPMyAdmin sur une base MariaDB :

Récupérer les données de podv2 en exportant les tables de la base de données, 
SAUF django_migrations 
SAUF live_broadcaster
Avec les options suivantes :
 - sans notion de clés étrangères (Désactiver la vérification des clés étrangères),
 - table IF NOT EXISTS,
 - Tronquer la table avant d'insérer,
 - Instructions INSERT IGNORE
 - Modifier USE `nomdelabase`; dans le fichier généré si nécessaire

Appeler le fichier généré podv2.sql.

Ce fichier podv2.sql est à copier sur le serveur principal de Pod v3 dans le répertoire /usr/local/django_projects.

Intégration des données dans Pod v3

Enfin, sur le serveur principal Pod v3, réaliser l'intégration totale :

cd /usr/local/django_projects/
mysql -h mariadb.univ.fr -u userpodv3 -pXXXX  podv3 < podv2.sql
=> cela peut provoquer des erreurs lors de la création des clés étrangères (qui existent déjà) si l'option n'a pas été décochée

# BD : Update Django_site
Modifier la table django_sites
	
# BD : Update de champs pour lesquels le site est par défaut à 0
update video_channel set site_id=1 where site_id=0;
update video_discipline set site_id=1 where site_id=0;

### Ajout des contenus pour Pod v3 ###
# Vérifier ce qu'il en est côté :
# - pages statiques (table django_flatpage)
# - diffuseurs (table live_broadcaster, penser que maintenant que l'accès est aussi au niveau des évènements)
# - évènements en direct (tables live_event et live_event_additional_owners)
# Si besoin, ajouter manuellement les informations manquantes via l'administration de Pod

Étapes suivantes

Ne pas oublier de redémarrer l'ensemble des services (uwsgi-pod, celeryd, rabbitmq-server, redis) sur les différents serveurs et penser à réindexer les vidéos pour Elasticsearch.