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

[Philippe Verdy]

Le 1 avril 2012 17:43, PierreV <belettepv at hotmail.fr> a écrit :
> Il faut arrêter de vouloir du résultat comme si c’était une entreprise...
> soyons déja contents que le projet est mis en place et sur la base du
> "libre" et donc laissez leur le temps... je trouve meme que 4 jours c'est
> cours pour le "volume" de donnés!!

La question du volume est hors de propos. Même pour copier plusieurs
téraoctets, il ne faut pas 4 jours, (surtout avec les disques actuels
puisqu'il s'agit d'installer un *nouveau* serveur tout neuf, et à
rpriori plus performant encore que l'ancien).

4 jours c'est veaucoup trop long pour un service qui a pris une
importance mondiale. Et faire tout dépendre techniquement d'un seul
serveur, c'est suicidaire. La réplication n'est plus un luxe et aurait
du être une priorité depuis longtemps (avant même le changement de
licence, qui ne se fera que sur le nouveau serveur parce que les
outils pour faire la migration demanderont de la performance et de
l'espace de stockage, et beaucoup de travail).

Aussi je comprend tout à fait qu'il ait fallu attendre un an pour
changer la licence et faire la migration des données puisque l'ancien
serveur n'aurait jamais tenu la charge (il avait déjà bien du mal à
suivre avec juste les mises à jour actuelles des utilisateurs).

Donc Ok pour le fait de démarrer le changement de licence seulement
maintenant. Mais en revanche je suis très critique sur les moyens et
solutions mis en œuvre pour *seulement* ne faire que changer de
serveur.

Techniquement il y a un problème sérieux, et si FOSM parvient
lui à démarrer dès le début en partant de rien pour charger toute la
base OSM, je ne comprends pas que la Fondation, bien plus riche, n'a
pas pu ou su monter aussi un autre serveur et le monter en charge
jusqu'à ce que son "lag "soit rattrapé, afin de n'arrêter le service
que quelques minutes lors du basculement entre le serveur principal et
le miroir.

En plus je trouve cet arrêt très risqué. Qui dit qu'il n'y aura pas
d'incident de migration et que cela ne prendra finalement pas plus de
4 jours ? En montant un serveur en parallèle jusqu'à ce qu'il ait
réussie à tout charger, le risque d'échec restait gérable: on pouvait
recommencer en cas de problème sans même rien arrêter du tout, l'échec
de migration restait invisible.

J'espère qu'il n'est pas question de prolonger ces 4 jours, et que dès
que le nouveau serveur sera opérationnel il sera mis en ligne même si
c'est avant. Mais en cas d'échec, hors de question de recommencer : on
redémarre l'ancien serveur aussitôt et on va chercher à régler le
problème de chargement du nouveau serveur. Je crois qu'il est
incroyable d'avoir du faire un arrêt aussi long, qui était
parfaitement **évitable **donc **inutile**.

Et pas question d'accepter alors un nouvel arrêt de 4 jours pour
recommencer en cas d'échec de la première migration de données ! OK le
projet est libre mais il a aussi des responsabilités à assumer pour
obtenir la confiance des contributeurs.

Et certes le changement de licence était annoncé, mais PAS un arrêt
total du service pendant 4 jours intervenu à la dernière minute
uniquement par suite d'une *décision* (mal justifiée techniquement) et
pas du tout à cause d'un incident imprévu.

Il n'y avait strictement aucun besoin d'une telle précipitation:
monter un nouveau serveur et le rendre opérationnel et synchornisé
aurait pu se faire pendant 15 jours ou même un mois, comme l'ont fait
d'autres (par exemple FOSM). Cette précipitation sur un projet de
cette taille non seulement fait courrir un risque élevé pour un projet
aussi important, mais justement au vu de la taille des données, ce
risque d'incident (normalement réparable)  ou contournable) est
presque inévitable.

Cette précipitation génère un stress de travail énorme sur ceux
chargés de monter et maintenir les systèmes, il met en péril
l'intégrité des données de façon plus importante (et il sera même
impossible d'en discuter ou de trouver des contournements intelligents
de certains problèmes techniques qu'OSM est incapable de prévoir, car
ils sont imprévus mais surviendront avec une quasi-certitude).

Bref je trouve qu'OSM a joué à la roulette russe dans l'histoire et
n'est pas à la hauteur de ses responsabilités. Car cette
planifiication surprise du changement de serveur, qui a pris de court
tout le monde, est réellement un désastre techniquement et pour
l'image d'OSM (indépendamment du changement de licence avec lequel OSM
a essayé de mêler les deux projets alors que ce sont deux opérations
indépendantes, toutes deux très larges et toutes deux risquées, et qui
n'auraient jamais du être tentées en même temps).

Car si on a eu le temps de planifier le changement de licence, rien
n'a permis aux contributeurs de s'attendre à un arrêt de 4 jours (et
encore, vu les moyens choisis et les risques pris, je ne suis même pas
certain que dans 4 jours, le nouveau serveur sera réellement
opérationnel, et réellement testé avant de commencer à faire exécuter
doucement puis plus rapidement les opérations de migration de
licence...).