Ce n'est pas lié directement au changement de licence (qui était déjà en place puisqu'on ne pouvait plus contribuer en CC-BY-SA), ni au nettoyage des données (qui aura lieu après le redémarrage du service, en tâche de fond), mais lié à un changement de serveur.
Malgré tout, un changement de serveur de base de données aurait pu avoir lieu bien avant et pourra encore avoir lieu à l'avenir. Je ne comprends pas la nécessité d'arrêter le service pendant 4 jours, alors qu'une solution de réplication aurait pu être utilisée, même si elle prenait du temps pour tout resynchroniser, sans même arrêter le service. Je comprends la nécessité de passer à un serveur plus puissant. Pas celle d'arrêter le service pendant 4 jours. Cela donne l'impresion forte que le service n'est pas solide et tehniquement pas au point. Au lieu de charger le nouveau serveur pendant 4 jours, il aurait peut-être fallu 15 jours jusqu'à ce que le nouveau serveur soit prêt (avec juste un lag time de quelques minutes, vite rattrapé quand l'ancien serveur a arrêté d'accepter les nouvelles données), et ensuite il n'aurait fallu qu'une interruption de quelques minutes pour faire la bascule du nouveau serveur miroir en tant que serveur principal, le temps de reconfigurer routeurs parefeux ou adresses IP et redémarrer les serveurs. L'ancien servant alors de serveur de secours ou pour héberger des services hors-ligne tels que des l'exécution de certains scripts de maintenance, ou l'hébergement d'une solution comparable à OSMI/Osmose, ou l'exécution de tâches comme la génération et la compression des dumps, ou encore pour augmenter la charge utile de certaines API. Bref le projet a besoin depuis longtemps de développer une solution de réplication en ligne, et cette solution n'a pas été développée. La solution de l'arrêt complet c'est la solution de facilité mais elle nuit au projet. De meˆme la bses de données aurait pu être splittée en plusieurs parties, par secteur angulaire, un serveur frontal collectant les données de l'un ou l'autre pour les accès en lecture (avec un minimum d'objets stocké dans les deux quand il y a des références mutuelles, pour l'intégrité référencielle). Pour cela il aurait juste fallu qu'au delà d'une certaine tranche d'identifiants, chacun puisse générer ses propres identifiants uniques dans des blocs de numéros préalloués pour chacun d'eux. Si à la prpchaine panne du serveur il faut encore 4 jours pour remonter un autre serveur, c'est que le projet n'est pas assez solide. La réplication avec consolidation aurait du être en place depuis longtemps, vu la taille du projet. Le 1 avril 2012 11:03, Christian Quest <cqu...@openstreetmap.fr> a écrit : > Effet(s) de bord de la migration... > > - plus possible de se connecter sur osm.org > - plus possible d'envoyer des messages à d'autres contributeurs > > Le soleil est revenu, ça sent la sortie mapping sur le terrain ;) > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-fr _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
