Closed maxlath closed 4 years ago
autre possibilité qui tire avantage de la containérisation docker : faire un autre repo wikibase sur le serveur avec la version 1.32, et charger/créer uniquement les éléments à merger. avantage: la version actuelle 1.33 n'est pas modifiée, les données non plus inconvénient: seule une des deux versions à la fois n'est accessible (à moins que l'on redirige vers d'autres ports)
merci pour les retours, j'ai vu avec Anila et Benjamin et :
On veut bien mettre en place un autre wikibase:1.32
, néanmoins on insiste sur les inconvénients et les solutions pour les contourner :
Une autre instance en fonctionnement nécessite de couper l'actuelle, si cela vous convient, c'est la solution à court terme la plus efficace.
Sinon il s'agira de servir le wikibase:1.32
sur un autre port local, et coté interface web sur un autre domaine pour que coté BnF le service soit accessible.
Apparemment certaines expérimentations ont commencé sur test.wikidata.org, peut-etre est-ce suffisant dans un premier temps pour décider et implémenter l'administration système du wikibase:1.32
(ports, domaines) ?
Ok avec le dernier commentaire (finalement... nos excuses pour les aller retour). Donc je rectifie : on continue à tester / expérimenter - pas d'autre intervention technique attendue sur ce ticket pour le moment, et donc on poursuit le sprint avec les autres tickets.
version local du ticket phabricator T233490 pour discuter de la manière dont nous pouvons nous adapter à cette situation dans le cadre du POC, laquelle est qu'en l'état de l'installation (
wikibase-1.33
), les opérations de fusion (wbmergeitems
) sont rejetés avec une erreur interne :Pistes pour sortir de l'impasse :
ticket nécessitant de trouver une solution à ce problème : #221 et #222 cc @gotnc