[OSM-talk-fr] OSM en read-only (était : Vélib' Paris)

[Cyrille Giquello]

Bonjour,

Je rejoins Philippe sur l'importance mondiale qu'a prit le projet OSM.
Il serait temps de définir une politique accompagnée de ses moyens
techniques pour être à la hauteur de toutes ces contributions qui font
d'OSM un fabuleux projet mondial. Un genre d'architecture distribuée
semble la voix à explorer.

Mes 2 centimes de techos
Cyrille.

Le 1 avril 2012 17:22, Philippe Verdy <verdy_p at wanadoo.fr> a écrit :
> 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 <cquest at 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 at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr



-- 
Cyrille.