Migration Plone 2.1

Plone est un système de gestion de contenus open source et gratuit. C'est la technologie derrière mon site. Dernièrement, les gens de chez Plone ont sorti une nouvelle version, la 2.1, qui apporte quelques nouveautés et améliorations, dont l'adoption d'Archetypes en tant que base des types de contenus, à la place des types CMF (Content Management Framework), utilisés depuis les débuts de Plone.

De fait, la migration de Plone 2.0.5 (ou antérieur) à Plone 2.1 (et supérieur) implique la migration automatique des anciens types de contenus, ce qui peut être à la fois long et laborieux. Dans mon cas, il s'agissait de migrer 4 sites répartis sur deux instances.

Première instance, le site web de ma boîte, plus un petit site perso. Le site web a un contenu majoritairement statique, composés de documents (CMFDocument), avec quelques fichiers PDF stockés en CMFFile. Le site perso est très réduit en taille, avec des documents et quelques photos. Le Data.fs de l'instance pèse dans les 500 Mo.

Deuxième instance, le site intranet de ma boîte, plus un site communautaire sur un artiste vietnamien. Le site intranet est très lourd, et chargé à bloc de fichiers PDF stockés en CMFFile, ainsi que des CMDDocuments. Le site communautaire est composé de documents en CMFDocument, de photos en CMFPhoto et de quelques chansons en MP3 (CMFFile). Le Data.fs fait environ 1 Go.

La procédure normale de migration de Plone (sur FreeBSD, ou d'autres Unix) est de tout d'abord, faire une sauvegarde complète du site, avec tous les produits (on sait jamais), télécharger le tarball de la nouvelle version de Plone sur leur site, placer les produits nouveaux et mis à jour dans le répertoire Products de l'instance, et lancer la mise à jour dans la ZMI par l'outil portal_migration, qui sait détecter la version installée, et qui effectue la migration tout seul comme un grand.

La migration en elle-même effectue la mise à jour des produits de support de Plone, comme Archetypes, et met à jour le site Plone en lui-même (avec les changements de paramètres, nouvelles variables, etc). Mais la migration en version 2.1 effectue une étape importante supplémentaire : elle convertit les éléménts CMFTypes du site en éléments Archetypes. Ça consiste en fait à prendre un objet CMFType, créer un nouvel objet Archetype équivalent, et à répliquer tous les paramètres et données au nouvel objet, et détruire l'objet CMFType. Ainsi on obtient un objet Archetype d'apparence identique à l'ancien objet CMFType.

Le script effectuant cette manœuvre recatalogue le site, trouve les objets CMFTypes à partir du portal_catalog, et les convertit. Or cette opération est longue et consommatrice de mémoire et d'espace disque temporaire.

La première erreur que j'ai eue, c'est No space left on device... En effet, l'interprêteur python qui effectuait la mise à jour a saturé le répertoire /tmp de la machine. En même temps, ce n'était pas très difficile, la taille par défaut de la partition abritant /tmp sur FreeBSD est de 256 Mo. Ce qui est suffisant pour la plupart des cas, mais là, les devs de Plone recommendaient au moins la taille du Data.fs pour la migration. Là, j'en étais loin... Normalement, python utilise tour à tour les répertoires /tmp, /var/tmp, /usr/tmp et le répertoire courant (et peut-être un autre, je sais plus) pour stocker les fichiers temporaires, et ne devrait théoriquement jamais se trouver à court d'espace disque avant la saturation totale de tous les disques. Mais là, il semble qu'il n'y a qu'un seul fichier utilisé pour la migration, et qui grossit pendant toute la durée de l'opération. Donc pas de fallback possible...

Du coup, j'ai monté une machine dédiée à la migration, avec une seule partition couvrant tout le disque. Plus de problème d'espace disque. Mais j'ai été confronté à des erreurs de type Memory Error... Et c'est à peu près les pires erreurs qu'on peut rencontrer dans Zope/Plone, ça veut dire en gros qu'il y a eu une erreur de lecture/écriture sur le Data.fs irrécupérable...

Au bout de deux ou trois échecs de migration directe, je me suis dit que je ne pouvais pas continuer comme ça : il y a tellement de choses qui sont faites dans la migration que je ne sais pas où s'est produit l'erreur, et l'opération met tellement de temps que j'en aurais pour des semaines avant de dépatouiller la chose à ce rythme.

J'ai alors essayé de comprendre la procédure. Et c'est pas bien sorcier. D'abord, essayer de nettoyer et alléger le fichier Data.fs pour faciliter la migration. Rien de compliqué, recataloguer le site (<site>/portal_catalog, onglet Advanced, Update Catalog),recompresser le fichier (Control_Panel/Database/main, onglet Database, Pack).

Ensuite, mettre à jour les produits déjà installés (par portal_quickinstaller. Ensuite, installer les nouveaux produits dont Plone a besoin (toujours par portal_quickinstaller). La version 2.1 apporte les produits suivants :

• ATContentTypes
• ATReferenceBrowserWidget
• Archetypes
• CMFActionIcons
• CMFCalendar
• CMFFormController
• CMFQuickInstallerTool
• GroupUserFolder
• MimetypesRegistry
• PloneErrorReporting
• PloneLanguageTool
• PortalTransforms
• PortalTransport
• ResourceRegistries
• kupu

Tout réinstaller/installer, sauf ATContentTypes. Une fois que les autres produits sont installés sans erreurs, on passe au point crucial, ATContentTypes.

ATContentTypes, c'est le produit qui apporte les types de contenus Archetypes (comme son nom l'indique). Or ça implique de recataloguer le site avant, et de créer un double Archetype de chaque objet CMFTypes du site, et enfin de supprimer les objets CMFTypes. Et c'est long !

A l'installation du produit, il y a un Update Catalog qui se fait, ça prend un moment (surtout si le site est grand). Une fois le produit installé, il faut passer aux choses sérieuses : portal_atct. C'est un outil placé par ATContentTypes à la racine du site. La première fois, si vous aviez déjà installé Archetypes avant, l'outil vous indiquera que l'instance n'est pas à jour. Il faudra passer par Version Migration pour ce faire.

Une fois que l'instance est à jour, il faut passer à la migration des types, dans Type Migration. Comme l'indique l'outil, pour cette étape, il vaut mieux lancer Zope en mode debug, ou consulter régulièrement le log de Zope, pour voir ce qu'il fabrique. Un clic sur Migrate lance la migration des types. Là j'ai connu l'enfer, avec des Memory Error inexplicables (pas de veleur d'erreur...).

Mais j'ai fini par voir qu'il y a au début du log le chemin complet de l'objet en cours quand l'erreur s'est produite. Pour moi, c'était à peu près tous les objets binaires (type octet-stream), comme des fichiers exécutables ou des fichiers Zip stockés en tant que CMFFile. Il est possible que notre utilisation de TextIndexNG2, un produit permettant une indexation plus fine des langues non latines, ait contrinué à cette erreur, car les index sont également regénérés lors de la migration des types. Peut-être que TextIndexNG2 n'a pas trouvé de "lecteur" approprié pour ces types et qu'il s'est emmêlé les pinceaux...

En tous cas, supprimer ces objets a suffi pour que la migration des types se fasse sans erreurs (mais bon, il faut relancer la migration de types autant de fois qu'il y a de fichiers problématiques).

Une fois les types migrés, c'est gagné. Il suffit d'utiliser l'outil portal_migration, et lancer la migration Plone. Il va alors repasser les étapes qu'on a déjà effectué, mais il ne fera rien ou presque, vu que tout est installé et migré côté Archetypes (mais la mise à jour du catalog va quand même se faire, et ça prend du temps...). Il va donc mettre à jour l'instance Plone, et le site sera opérationnel sous la nouvelle version !

Merci d'avoir lu jusqu'ici, c'est brouillon parce que mes tentatives de migration ont été brouillonnes, mais j'espère que ça pourra vous aider si vous rencontrez des problèmes pendant la migration.