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

Dim 1 Avr 21:40:41 UTC 2012


Comme tu n es pas en contact avec les admins de la base OSM et que tu juges leurs decisions/actions sans savoir ce qu ils font voici leurs adresses mails : Tom Hughes <tom at compton.nu>; et openstreetmap at firefishy.com <openstreetmap at firefishy.com>;
Tu as plein de choses interessantes a leur expliquer et a leur apprendre, pense a garder au moins la liste osm-fr-dev en copie afin  que nous puissions apprecier pleinements tes contributions


Julien


>________________________________
> De : Philippe Verdy <verdy_p at wanadoo.fr>
>À : f.dos.santos at free.fr 
>Cc : Discussions sur OSM en français <talk-fr at openstreetmap.org> 
>Envoyé le : Dimanche 1 avril 2012 23h24
>Objet : Re: [OSM-talk-fr] OSM en read-only (était : Vélib' Paris)
> 
>Le 1 avril 2012 21:54,  <f.dos.santos at free.fr> a écrit :
>> Aucune prise de pouvoir : c'est son *role* de gerer l'infrastructure et je ne
>> vois pas ce que l'on sacrifie en faisant un pgdump + pgrestore !
>
>Un administrateur qui fait son travail son communiquer sur ce qu'il
>veut faire, ou a fait, n'est pas un bon administrateur.
>
>> "Toute bonne migration se fait par petites étapes qui passent
>> presque inaperçues"
>> Migration sur nouveau serveur et adaptation API qui vont surement passé inaperçu
>> quand la base sera de nouveau en ligne.
>
>C'est un apriori. Non décrit dans le plan de migration en court.
>
>> "la base sera beaucoup plus « nettoyée » que ce qui a été annoncé"
>> Pas de soucis à se faire vu qu'il n'y a aucun nettoyage.
>
>Etant donné le plan d'urgence des 4 jours donnés pour faire le
>travail, ils n'auront guère d'autre choix que de sacrifier une partie
>des données en cas de problèmes, sinon ils ne redémarrent pas !
>
>> "car justement ces administrateurs n'ont pas le temps de communiquer"
>> Un admin ça administre c'est pas fait pour faire de la comm.
>
>Un administrateur qui fait son travail son communiquer sur ce qu'il
>veut faire, ou a fait, n'est pas un bon administrateur, en tout cas
>pas pour ce type de projet collaboratif. D'une façon ou d'une autre,
>s'il n'a pas le temps de le faire, il lui faut quelqu'un à côté de lui
>pour surveiller tout ce qu'il fait, ou des outils (journaux, etc.)
>permettant de tracer toutes ses actions.
>
>> "On ne sait pas si les décisions prises sur une partie seront
>> réversibles et si on aura même la possibilité de repérer ce qui
>> manque"
>> Tu radotes
>
>Non. Le rique est réel.
>
>> "Car le processus de migration n'a de serveur pas été documenté"
>> Si là : http://lists.openstreetmap.org/pipermail/announce/2012-March/000061.html
>> Technical: pg_dump (smaug) to pg_restore -j x (ramoth). Upgrading from
>> PostgreSQL 8.4 to PostgreSQL 9.1
>
>On croise les doigts pour qu'il n'y ait que ça. Ayant déjà fait des
>migrtions de bases de données dans le passé, on a toujours rencontré
>des problèmes de compatibilité sur des bases de données très
>volumineuses. Pour passer le problème, on sacrifie une partie des
>données non convertibles (ou mal converties et rejetées dans le
>nouveaux schéma).
>
>Après reste à résoudre le problème de ces données manquantes (à
>condition de les avoir identifiées, conservées à part, afin de trouver
>une solution ultérieure pour elles, et analyser proprement pourquoi
>elles n'ont pas été acceptées et ce qu'on peut faire pour les
>corriger. Sur des données aussi volumineuses, ces données en conflit
>peuvent elles aussi être très volumineuses et demander plus que 4
>jours pour les convertir proprement, au moins en partie, tout en
>sachant précisément ce qu'on ne pourra pas préserver et pourquoi, afin
>de pouvoir vérifier aussi l'intégrité des données qui sont passées.
>
>> "Alors je croise les doigts pour que les historiques complets (au moins
>> la dernière modification par un utilisateur avant celle d'un
>> utilisateur qui ne l'a pas acceptée ou qui l'a refusé) restent
>> accessibles même sur la nouvelle base."
>> Oui l'historique est préservé.
>>
>> Pour l'histoire de la réplication, on migre sur un PostgreSQL 9.1 justement pour
>> ça.
>
>Et il n'est pas inintéressant de lire les notes de compatibilité entre
>PosrtgreSQL 9.1 et les anciennes versions. La page suivante en donne
>seulement une idée sommaire (le détail est plus compliqué si on tient
>compte de la plateforme matérielle ou OS) :
>
>http://www.postgresql.org/docs/9.1/static/release-9-1-3.html
>
>Ainsi que les notes de bogues existants pour ces migrations. Car il y en a !
>
>http://www.postgresql.org/docs/9.1/static/release-9-1.html
>
>Certains outils ont des bogues jugés « non critiques » comme des
>fuites mémoire, qui pourtant commenceront à tout planter au milieu
>passé un certain volume de données traitées. D'autres choses concerne
>la stabilité des tris et index. La compatibilité des critères
>d'unicité pour les collations (changement de version des bases CLDR ou
>Unicode par exemple).
>
>Aussi, la compatibilité des systèmes I/O (en cas de changement de
>version de l'OS hôte ou de son architecture matérielle). Des
>contraintes liées aux processeurs pour la synchronisation multithread
>(certaines procédures SQL qui n'avaient à priori pas besoin de
>synchronisation vont en avoir besoin, ou bien il y a de nouveaux
>deadlocks entre sections critiques, générant des erreurs SQL et des
>rollbacks implicites de transactions qui passaient sans problèmes
>avant).
>
>Des différences aussi dans la syntaxe SQL ou le support des plugins
>GIS, ou dans la version du noyau de VM si le moteur supporte les
>traitements dans une VM intégrée au moteur, tel que Java, ou des
>différences de comportement et de compatibilité avec d'autres plugins
>en code natif (certains intégrant des mots-clés, fonctions, types SQL
>supplémentaires, ou de nouvelles méthodes d'indexation et de recherche
>et jointure), ou de nouvelles restrictions de sécurité. Espérons que
>le logiciel a déjà été testé sur le nouveau serveur, avec un jeu de
>données de test significatif qui sera effacé, avant de commencer la
>migration des données réelles elles-mêmes.
>
>Et que les interfaces disque/réseau n'ont pas de soucis matériel en
>cas de montée en charge (les tests sur un jeu de données réduit ne
>suffisant pas, il faut aussi normalement les compléter en important
>massivement des données quasi-aléatoires générées par un petit script
>répliquant tous les cas, y compris avec des index déséquilibrés). Mais
>il est notoirement très difficile de simuler l'activité réelle des
>requêtes venant du réseau, ainsi que celles générées par les diverses
>API développées (y compris celle des dumps destinés à être
>redistribués publiquement, qui doivent pouvoir tourner aussi sans
>planter ou bloquer tout le reste).
>
>Encore plus difficile à prévoir : des différences notables de
>performance (pas toujours meilleure dans tous les cas !) dont l'effet
>peut être inattendu voire même s'avérer très bloquant pour certaines
>requêtes (les index sont sensibles aux changements d'algorithmes
>internes, qui souvent ne sont faits et optimisés que pour répondre à
>certaines heuristiques "classiques"), à cause de nouvelles
>vérifications de contraintes référentielles (l'algo optimisé passe
>alors dans un mode de compatibilité bien plus lent que l'ancien algo
>seul). On note aussi des différences de volumétrie notables de
>certains index paginés (liés parfois à des contraintes matérielles
>d'alignement de données, soit pour le processeur lui-même soit pour
>les systèmes d'I/O).
>
>Plus jamais je ne recommanderai une migration de type Big Bang qu'on
>ne sait pas mener en quelques minutes d'installation. plusieurs jours
>c'est beaucoup trop, surtout s'il y a de nombreux utilisateurs qui en
>dépendent (que ces utilisateurs payent ou soient payés ou non pour les
>utiliser, et surtout si ces utilisateurs sont externes et hors de
>contrôle direct de celui qui commande la migration de l'application).
>Car je sais que de telles migration peuvent prendre jusqueà 10 fois
>plus de temps que prévu.: une migration prévue de quelques minutes qui
>prendrait la nuit, ça passe encore, après ça, on y risque sa santé ou
>son job à la roulette russe, et la survie de l'organisation qui l'a
>demandée, même si elle a pris certaines assurances !
>
>Et même quand on commence une telle migration Big Bang (supposée durer
>quelques minutes), il doit toujours être possible de l'annuler en
>cours et continuer en s'en passant (pour la reprendre plus tard quand
>on pourra si jamais on la recommence après avoir identifié la source
>des problèmes et les moyens de le contourner), car on a toujours des
>surprises inattendues (pas toujours positives) sur les performances
>réelles du processus. Ce qui veut dire que d'autres prejets ne
>devraient pas en dépendre directement ou devraient prévoir une
>alternative possible en cas de défaut. De tels plans de repli immédiat
>doivent être prêts avant même de commencer la migration.
>
>4 jours de travail prévus (même seulement pour surveiller comment ça
>se passe) c'est beaucoup, et les administrateurs rentrent aussi chez
>eux et ont besoin de dormir s'il veulent éviter des erreurs de
>manipulation (ils ne seront pas toujours là dans les 4 jours, ils
>peuvent se relayer mais oublier de se transmettre des infos sur ce qui
>a déjà été fait ou reste à faire, même avec le meilleur plan préparé,
>d'une façon ou d'une autre ils faut qu'ils se débrouillent avec leurs
>propres moyens et prennent seuls des décisions immédiates et pas
>toujours notées).
>
>_______________________________________________
>Talk-fr mailing list
>Talk-fr at openstreetmap.org
>http://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20120401/56ebb590/attachment-0001.htm>