Re: [OSM-talk-fr] résumés des problèmes majeurs du rendu osm-fr et osm.org
De plus le graphe munin indique clairemetn qu'Orm n'est pas hors production mais est en cours de rattrapage de son retard de base de données, donc qu'il a été réactivé (même si pour l'instant il ne produit pas encore de tuiles puisque sa base est en cours de rechargement et resynchronisation (c'est très clair sur le graphe). Le sam. 11 août 2018 à 16:01, Philippe Verdy a écrit : > Apparement les liens munin indiquent toujours que Orm est en prod, et > aucun lien pour rhaegal. Ces liens ne sont peut-être pas encore à jour, et > rhaegal est alors un nouveau serveur remplaçant orm (ce dont j'ai > maintenant un doute vu que le graphe munion le mentionne **maintenant** > comme 5e serveur en plus d'Orm (il n'y en avait encore que 4 quand je > l'avais vérifié). > > J'avais justement pris la peine de vérifier les liens avant de poster, ce > n'était pas des "suppositions". Je donne des pistes parce que le détail tu > as oublié de le donner. Maintenant si tu as des infos plus "directes"... > > > Le sam. 11 août 2018 à 11:31, marc marc a > écrit : > >> Tu fais des suppositions de suppositions qui au final se transforment >> en errer, un exemple : >> >> Le 11. 08. 18 à 05:27, Philippe Verdy a écrit : >> > Les 4 serveurs de rendus d'OMS.org sont "yevaud", "vial", "scorch", >> > et "orm" (et non pas "rhaegal" ou c'est un ancien alias). >> >> information de Tom Hughes (celui qui a les mains dans le cambouis >> pour les serveurs osm.org) : >> >> orm n'est actuellement pas un serveur de rendu en production, >> il a été retiré le 7 août suite à un autre soucis en cours >> de résolution >> >> rhaegal est un serveur de rendu en production >> >> ces 2 infos sont aussi visible sur les graphes munin si tu avais >> pris la peine de la peine de cliquer sur le lien donné avant >> de dire que les infos venant de ceux qui FONT sont erronées >> https://munin.openstreetmap.org/renderd-day.html >> ___ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr >> > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] résumés des problèmes majeurs du rendu osm-fr et osm.org
Apparement les liens munin indiquent toujours que Orm est en prod, et aucun lien pour rhaegal. Ces liens ne sont peut-être pas encore à jour, et rhaegal est alors un nouveau serveur remplaçant orm (ce dont j'ai maintenant un doute vu que le graphe munion le mentionne **maintenant** comme 5e serveur en plus d'Orm (il n'y en avait encore que 4 quand je l'avais vérifié). J'avais justement pris la peine de vérifier les liens avant de poster, ce n'était pas des "suppositions". Je donne des pistes parce que le détail tu as oublié de le donner. Maintenant si tu as des infos plus "directes"... Le sam. 11 août 2018 à 11:31, marc marc a écrit : > Tu fais des suppositions de suppositions qui au final se transforment > en errer, un exemple : > > Le 11. 08. 18 à 05:27, Philippe Verdy a écrit : > > Les 4 serveurs de rendus d'OMS.org sont "yevaud", "vial", "scorch", > > et "orm" (et non pas "rhaegal" ou c'est un ancien alias). > > information de Tom Hughes (celui qui a les mains dans le cambouis > pour les serveurs osm.org) : > > orm n'est actuellement pas un serveur de rendu en production, > il a été retiré le 7 août suite à un autre soucis en cours > de résolution > > rhaegal est un serveur de rendu en production > > ces 2 infos sont aussi visible sur les graphes munin si tu avais > pris la peine de la peine de cliquer sur le lien donné avant > de dire que les infos venant de ceux qui FONT sont erronées > https://munin.openstreetmap.org/renderd-day.html > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] résumés des problèmes majeurs du rendu osm-fr et osm.org
Ok merci pour toutes ces clarifications. C'est un super compte rendu. Au moins je comprends mieux ces histoires de délais de mise à jour de tuiles... De mon côté c'est Scorch qui déconne. Bon week-end Le sam. 11 août 2018 11:30, marc marc a écrit : > Tu fais des suppositions de suppositions qui au final se transforment > en errer, un exemple : > > Le 11. 08. 18 à 05:27, Philippe Verdy a écrit : > > Les 4 serveurs de rendus d'OMS.org sont "yevaud", "vial", "scorch", > > et "orm" (et non pas "rhaegal" ou c'est un ancien alias). > > information de Tom Hughes (celui qui a les mains dans le cambouis > pour les serveurs osm.org) : > > orm n'est actuellement pas un serveur de rendu en production, > il a été retiré le 7 août suite à un autre soucis en cours > de résolution > > rhaegal est un serveur de rendu en production > > ces 2 infos sont aussi visible sur les graphes munin si tu avais > pris la peine de la peine de cliquer sur le lien donné avant > de dire que les infos venant de ceux qui FONT sont erronées > https://munin.openstreetmap.org/renderd-day.html > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] résumés des problèmes majeurs du rendu osm-fr et osm.org
Tu fais des suppositions de suppositions qui au final se transforment en errer, un exemple : Le 11. 08. 18 à 05:27, Philippe Verdy a écrit : > Les 4 serveurs de rendus d'OMS.org sont "yevaud", "vial", "scorch", > et "orm" (et non pas "rhaegal" ou c'est un ancien alias). information de Tom Hughes (celui qui a les mains dans le cambouis pour les serveurs osm.org) : orm n'est actuellement pas un serveur de rendu en production, il a été retiré le 7 août suite à un autre soucis en cours de résolution rhaegal est un serveur de rendu en production ces 2 infos sont aussi visible sur les graphes munin si tu avais pris la peine de la peine de cliquer sur le lien donné avant de dire que les infos venant de ceux qui FONT sont erronées https://munin.openstreetmap.org/renderd-day.html ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] résumés des problèmes majeurs du rendu osm-fr et osm.org
Voir aussi cette page de doc de wget au sujet des "timestamps". https://www.gnu.org/software/wget/manual/html_node/Time_002dStamping-Usage.html Et la note concernant FTP: https://www.gnu.org/software/wget/manual/html_node/FTP-Time_002dStamping-Internals.html#FTP-Time_002dStamping-Internals Le sam. 11 août 2018 à 05:57, Philippe Verdy a écrit : > Une piste à propos de Wget (voir http://www.gnu.org/software/wget/) qui > indique : > "Uses local file timestamps to determine whether documents need to be > re-downloaded when mirroring" > > Note: "wget" peut utiliser HTTP ou FTP, mais les serveurs FTP sont connus > pour ne pas afficher la date UTC mais uniquement la date locale du serveur > source : le client FTP ne sait pas quell est la date locale du serveur ! En > HTTP la précision du fuseau est normalement obligatoire dans les entêtes > MIME, ce n'est pas le cas de FTP. La note ci-dessus peut indiquer un > changement pour qu'en HTTP, wget se comporte comme en FTP (et cela suppose > donc alors que le client positionne d'abord sa date locale avec le fuseau > horaire du serveur interrogé avant d'utiliser "wget")... Ce serait bien de > vérifier ça si wget a bien été modifié sur la façon d'interpréter les dates > indiquées par le serveur distant: le serveur distant étant en HTTP ici, il > doit préciser ce fuseau, mais l'info est perdue/ignorée en cours de route. > > > Le sam. 11 août 2018 à 05:45, Philippe Verdy a > écrit : > >> Il toutefois que la synchro des diffs est basée sur les dates rapportées >> par https://tile.openstreetmap.org/cgi-bin/debug >> Il n'est pas clairement précisé dans ce "debug" comment est calculée >> cette date : est-ce une date "UTC" ou une date locale ? Sachant que les >> déménagement d'un serveur de Londres à Amsterdam change la date locale d'1 >> heure avec le changement de fuseau horaire. Reste à savoir de quel serveur >> viennent ces diffs sources: ils étaient générés à Londres sur l'instance >> principale, qui a été déménagée à Amsterdam. >> >> Un des outils d'Ubuntu a pu changer la date affichée par défaut pour >> passer de l'heure UTC à l'heure locale du serveur... >> Ce serait donc bien lié au déménagement d'une partie des serveurs. Mais >> le bogue serait lié à une soucis de compatibilité d'un des utilitaires >> d'Ubuntu mis à jour. >> >> Cela n'explique pas complètement pourquoi "Vial" (qui est resté en >> Allemagne) n'est pas affecté par le changement de date locale sur le >> serveur de base de données principal (déménagé de Londres à Amsterdam), >> mais on doit noter que lui n'a pas encore eu la mise à jour vers Ubuntu >> 18.04. >> >> On doit chercher du côté de l'outil de téléchargement des diffs utilisé >> sur les serveurs esclaves (probablement "wget"). Ce serait un bogue de >> compatibilité de cet outil dans la façon de gérer et rapporter les dates >> (locales ou UTC) : le serveur principal omet de préciser son fuseau horaire >> (mais si le protocole est HTTP ou HTTPS, normalement ce fuseau horaire est >> précisé dans les entêtes HTTP), et le script sur le serveur escalve faisant >> la requête HTTP interprète alors la date de façon différente en Ubuntu >> 18.04 si le fuseau n'est pas précisé (16.04: supposerait que la date est >> indiquée en UTC; 18.04 : supposerait que la date est indiquée dans la date >> locale du serveur local) >> >> >> >> >> >> Le sam. 11 août 2018 à 05:27, Philippe Verdy a >> écrit : >> >>> >>> le serveur utilisé actuellement dépend de la position géographique principalement mais peux aussi changer en cas de surcharge, info vérifiable en temps réel avec https://tile.openstreetmap.org/cgi-bin/debug les 2 serveurs ok : Yevaud et Vial les 2 serveurs affectés : Scorch et Rhaegal >>> >>> Les 4 serveurs de rendus d'OMS.org sont "yevaud", "vial", "scorch", et >>> "orm" (et non pas "rhaegal" ou c'est un ancien alias). >>> - "Yevaud" est encore à Londres (à l'UCL), mais n'a pas eu la mise à >>> jour d'Ubuntu 16.04 vers 18.04, il n'est pas affecté par le bogue >>> - "Vial" est en Allemagne (à Hetzner), mais n'a pas eu la mise à jour >>> d'Ubuntu 16.04 vers 18.04, il n'est pas affecté par le bogue >>> - "Scorch" est en France (à Roubais chez OVH): il est affecté par le >>> bogue, Ubuntu été mis à jour de 16.04 vers 18.04 >>> - "Orm" était parmi les serveurs déménagés de Londres (à l'UCL) à >>> Amsterdam (chez Equinix): il est affecté par le bogue, Ubuntu été mis à >>> jour de 16.04 vers 18.04 >>> >>> La mise à jour d'Ubuntu n'explique pas le rendu incorrect et la >>> persistence de ways parasites (marqués comme supprimés dans les "diffs" >>> mais qui sont tracés avec une partie des noeuds conservés par ailleurs). Il >>> semble que l'impact de cette mise à jour serait que les fichiers "diffs" >>> seraient traités alors qu'ils ne sont pas complètement téléchargés : le >>> traitement se fait sur une partie seulement des changesets qui sont alors >>> tronqués. >>> >>> Ce n'est apparemment pas un problème de base de données
Re: [OSM-talk-fr] résumés des problèmes majeurs du rendu osm-fr et osm.org
Une piste à propos de Wget (voir http://www.gnu.org/software/wget/) qui indique : "Uses local file timestamps to determine whether documents need to be re-downloaded when mirroring" Note: "wget" peut utiliser HTTP ou FTP, mais les serveurs FTP sont connus pour ne pas afficher la date UTC mais uniquement la date locale du serveur source : le client FTP ne sait pas quell est la date locale du serveur ! En HTTP la précision du fuseau est normalement obligatoire dans les entêtes MIME, ce n'est pas le cas de FTP. La note ci-dessus peut indiquer un changement pour qu'en HTTP, wget se comporte comme en FTP (et cela suppose donc alors que le client positionne d'abord sa date locale avec le fuseau horaire du serveur interrogé avant d'utiliser "wget")... Ce serait bien de vérifier ça si wget a bien été modifié sur la façon d'interpréter les dates indiquées par le serveur distant: le serveur distant étant en HTTP ici, il doit préciser ce fuseau, mais l'info est perdue/ignorée en cours de route. Le sam. 11 août 2018 à 05:45, Philippe Verdy a écrit : > Il toutefois que la synchro des diffs est basée sur les dates rapportées > par https://tile.openstreetmap.org/cgi-bin/debug > Il n'est pas clairement précisé dans ce "debug" comment est calculée cette > date : est-ce une date "UTC" ou une date locale ? Sachant que les > déménagement d'un serveur de Londres à Amsterdam change la date locale d'1 > heure avec le changement de fuseau horaire. Reste à savoir de quel serveur > viennent ces diffs sources: ils étaient générés à Londres sur l'instance > principale, qui a été déménagée à Amsterdam. > > Un des outils d'Ubuntu a pu changer la date affichée par défaut pour > passer de l'heure UTC à l'heure locale du serveur... > Ce serait donc bien lié au déménagement d'une partie des serveurs. Mais le > bogue serait lié à une soucis de compatibilité d'un des utilitaires > d'Ubuntu mis à jour. > > Cela n'explique pas complètement pourquoi "Vial" (qui est resté en > Allemagne) n'est pas affecté par le changement de date locale sur le > serveur de base de données principal (déménagé de Londres à Amsterdam), > mais on doit noter que lui n'a pas encore eu la mise à jour vers Ubuntu > 18.04. > > On doit chercher du côté de l'outil de téléchargement des diffs utilisé > sur les serveurs esclaves (probablement "wget"). Ce serait un bogue de > compatibilité de cet outil dans la façon de gérer et rapporter les dates > (locales ou UTC) : le serveur principal omet de préciser son fuseau horaire > (mais si le protocole est HTTP ou HTTPS, normalement ce fuseau horaire est > précisé dans les entêtes HTTP), et le script sur le serveur escalve faisant > la requête HTTP interprète alors la date de façon différente en Ubuntu > 18.04 si le fuseau n'est pas précisé (16.04: supposerait que la date est > indiquée en UTC; 18.04 : supposerait que la date est indiquée dans la date > locale du serveur local) > > > > > > Le sam. 11 août 2018 à 05:27, Philippe Verdy a > écrit : > >> >> le serveur utilisé actuellement dépend de la position géographique >>> principalement mais peux aussi changer en cas de surcharge, >>> info vérifiable en temps réel avec >>> https://tile.openstreetmap.org/cgi-bin/debug >>> les 2 serveurs ok : Yevaud et Vial >>> les 2 serveurs affectés : Scorch et Rhaegal >>> >> >> Les 4 serveurs de rendus d'OMS.org sont "yevaud", "vial", "scorch", et >> "orm" (et non pas "rhaegal" ou c'est un ancien alias). >> - "Yevaud" est encore à Londres (à l'UCL), mais n'a pas eu la mise à jour >> d'Ubuntu 16.04 vers 18.04, il n'est pas affecté par le bogue >> - "Vial" est en Allemagne (à Hetzner), mais n'a pas eu la mise à jour >> d'Ubuntu 16.04 vers 18.04, il n'est pas affecté par le bogue >> - "Scorch" est en France (à Roubais chez OVH): il est affecté par le >> bogue, Ubuntu été mis à jour de 16.04 vers 18.04 >> - "Orm" était parmi les serveurs déménagés de Londres (à l'UCL) à >> Amsterdam (chez Equinix): il est affecté par le bogue, Ubuntu été mis à >> jour de 16.04 vers 18.04 >> >> La mise à jour d'Ubuntu n'explique pas le rendu incorrect et la >> persistence de ways parasites (marqués comme supprimés dans les "diffs" >> mais qui sont tracés avec une partie des noeuds conservés par ailleurs). Il >> semble que l'impact de cette mise à jour serait que les fichiers "diffs" >> seraient traités alors qu'ils ne sont pas complètement téléchargés : le >> traitement se fait sur une partie seulement des changesets qui sont alors >> tronqués. >> >> Ce n'est apparemment pas un problème de base de données (sur la base de >> données esclave), mais des outils de téléchargement et synchronisation de >> répertoires (je ne sais pas si cela se fait par "rsync" ou pour un script >> shell avec "wget", mais cet outil ne semble pas correctement synchronisé >> avec l'outil qui va ensuite traiter les nouveau diffs reçus et "prêts" pour >> les charger sur la base esclave, une ancienen opération qui était bloquante >> semble être devenue asynchrone et il manque une étape
Re: [OSM-talk-fr] résumés des problèmes majeurs du rendu osm-fr et osm.org
Il toutefois que la synchro des diffs est basée sur les dates rapportées par https://tile.openstreetmap.org/cgi-bin/debug Il n'est pas clairement précisé dans ce "debug" comment est calculée cette date : est-ce une date "UTC" ou une date locale ? Sachant que les déménagement d'un serveur de Londres à Amsterdam change la date locale d'1 heure avec le changement de fuseau horaire. Reste à savoir de quel serveur viennent ces diffs sources: ils étaient générés à Londres sur l'instance principale, qui a été déménagée à Amsterdam. Un des outils d'Ubuntu a pu changer la date affichée par défaut pour passer de l'heure UTC à l'heure locale du serveur... Ce serait donc bien lié au déménagement d'une partie des serveurs. Mais le bogue serait lié à une soucis de compatibilité d'un des utilitaires d'Ubuntu mis à jour. Cela n'explique pas complètement pourquoi "Vial" (qui est resté en Allemagne) n'est pas affecté par le changement de date locale sur le serveur de base de données principal (déménagé de Londres à Amsterdam), mais on doit noter que lui n'a pas encore eu la mise à jour vers Ubuntu 18.04. On doit chercher du côté de l'outil de téléchargement des diffs utilisé sur les serveurs esclaves (probablement "wget"). Ce serait un bogue de compatibilité de cet outil dans la façon de gérer et rapporter les dates (locales ou UTC) : le serveur principal omet de préciser son fuseau horaire (mais si le protocole est HTTP ou HTTPS, normalement ce fuseau horaire est précisé dans les entêtes HTTP), et le script sur le serveur escalve faisant la requête HTTP interprète alors la date de façon différente en Ubuntu 18.04 si le fuseau n'est pas précisé (16.04: supposerait que la date est indiquée en UTC; 18.04 : supposerait que la date est indiquée dans la date locale du serveur local) Le sam. 11 août 2018 à 05:27, Philippe Verdy a écrit : > > le serveur utilisé actuellement dépend de la position géographique >> principalement mais peux aussi changer en cas de surcharge, >> info vérifiable en temps réel avec >> https://tile.openstreetmap.org/cgi-bin/debug >> les 2 serveurs ok : Yevaud et Vial >> les 2 serveurs affectés : Scorch et Rhaegal >> > > Les 4 serveurs de rendus d'OMS.org sont "yevaud", "vial", "scorch", et > "orm" (et non pas "rhaegal" ou c'est un ancien alias). > - "Yevaud" est encore à Londres (à l'UCL), mais n'a pas eu la mise à jour > d'Ubuntu 16.04 vers 18.04, il n'est pas affecté par le bogue > - "Vial" est en Allemagne (à Hetzner), mais n'a pas eu la mise à jour > d'Ubuntu 16.04 vers 18.04, il n'est pas affecté par le bogue > - "Scorch" est en France (à Roubais chez OVH): il est affecté par le > bogue, Ubuntu été mis à jour de 16.04 vers 18.04 > - "Orm" était parmi les serveurs déménagés de Londres (à l'UCL) à > Amsterdam (chez Equinix): il est affecté par le bogue, Ubuntu été mis à > jour de 16.04 vers 18.04 > > La mise à jour d'Ubuntu n'explique pas le rendu incorrect et la > persistence de ways parasites (marqués comme supprimés dans les "diffs" > mais qui sont tracés avec une partie des noeuds conservés par ailleurs). Il > semble que l'impact de cette mise à jour serait que les fichiers "diffs" > seraient traités alors qu'ils ne sont pas complètement téléchargés : le > traitement se fait sur une partie seulement des changesets qui sont alors > tronqués. > > Ce n'est apparemment pas un problème de base de données (sur la base de > données esclave), mais des outils de téléchargement et synchronisation de > répertoires (je ne sais pas si cela se fait par "rsync" ou pour un script > shell avec "wget", mais cet outil ne semble pas correctement synchronisé > avec l'outil qui va ensuite traiter les nouveau diffs reçus et "prêts" pour > les charger sur la base esclave, une ancienen opération qui était bloquante > semble être devenue asynchrone et il manque une étape de validation des > téléchargements de diffs effectivement terminés avant de placer ces > fichiers dans la file d'attente à traiter pour l'import). > > > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] résumés des problèmes majeurs du rendu osm-fr et osm.org
> le serveur utilisé actuellement dépend de la position géographique > principalement mais peux aussi changer en cas de surcharge, > info vérifiable en temps réel avec > https://tile.openstreetmap.org/cgi-bin/debug > les 2 serveurs ok : Yevaud et Vial > les 2 serveurs affectés : Scorch et Rhaegal > Les 4 serveurs de rendus d'OMS.org sont "yevaud", "vial", "scorch", et "orm" (et non pas "rhaegal" ou c'est un ancien alias). - "Yevaud" est encore à Londres (à l'UCL), mais n'a pas eu la mise à jour d'Ubuntu 16.04 vers 18.04, il n'est pas affecté par le bogue - "Vial" est en Allemagne (à Hetzner), mais n'a pas eu la mise à jour d'Ubuntu 16.04 vers 18.04, il n'est pas affecté par le bogue - "Scorch" est en France (à Roubais chez OVH): il est affecté par le bogue, Ubuntu été mis à jour de 16.04 vers 18.04 - "Orm" était parmi les serveurs déménagés de Londres (à l'UCL) à Amsterdam (chez Equinix): il est affecté par le bogue, Ubuntu été mis à jour de 16.04 vers 18.04 La mise à jour d'Ubuntu n'explique pas le rendu incorrect et la persistence de ways parasites (marqués comme supprimés dans les "diffs" mais qui sont tracés avec une partie des noeuds conservés par ailleurs). Il semble que l'impact de cette mise à jour serait que les fichiers "diffs" seraient traités alors qu'ils ne sont pas complètement téléchargés : le traitement se fait sur une partie seulement des changesets qui sont alors tronqués. Ce n'est apparemment pas un problème de base de données (sur la base de données esclave), mais des outils de téléchargement et synchronisation de répertoires (je ne sais pas si cela se fait par "rsync" ou pour un script shell avec "wget", mais cet outil ne semble pas correctement synchronisé avec l'outil qui va ensuite traiter les nouveau diffs reçus et "prêts" pour les charger sur la base esclave, une ancienen opération qui était bloquante semble être devenue asynchrone et il manque une étape de validation des téléchargements de diffs effectivement terminés avant de placer ces fichiers dans la file d'attente à traiter pour l'import). ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] résumés des problèmes majeurs du rendu osm-fr et osm.org
Le 11. 08. 18 à 00:23, marc marc a écrit : > les 2 serveurs ok : Yevaud et Vial > les 2 serveurs affectés : Scorch et Rhaegal arf cela concernait le bug osm2pgsql et non la saturation des files des serveurs de rendu ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] résumés des problèmes majeurs du rendu osm-fr et osm.org
email séparé pour éviter la noyade avec les autres problèmes :) ultra résumé pour ceux qui n'ont pas envie de tous lire : - il y a des bugs en cours de résolution tant sur le rendu osm.org que sur le rendu osm-fr - faire un /dirty sur les zoom faible ne sert a rien car ignoré - les zooms faible ont une fréquence de maj faible. version longue : 2 soucis majeurs avec le rendu osm.org : - bug lié à la maj de osm2pgsql lié à maj ubuntu 18.04 Christian a détaillé le bug survenu pour le rendu osm-fr lors de la maj osm2pgsql, c'est exactement la même cause qui affecte maintenant le rendu osm.org un peu différemment. le ticket des maj os https://github.com/openstreetmap/operations/issues/220 le commit qui aurait été fait il y a 3j https://github.com/openstreetmap/chef/commit/b2d0ed3e9e4f2fc899db7265a23156d5dd5cf139 la reconstruction du fichier est toujours en cours - les files d'attente des différents serveur de rendu sont souvent pleine en journée. donc si on modifie quelque chose en journée, la modif est bien sauvegardée mais la tuile n'est pas automatiquement maj. la prochaine visite de la page après le délais du cache provoquera une demande de maj de la tuile (sous réserve qu'il y ai de la place) maj qui serra visible tout de suite si la tuile est calculée rapidement (par ex en z19) ou ne serra elle aussi visible qu'à l'expiration de l'ancienne tuile si la maj n'a pas pu se faire assez vite la file d'attente des serveurs de rendu osm.org sont visible ici https://munin.openstreetmap.org/renderd-day.html le serveur utilisé actuellement dépend de la position géographique principalement mais peux aussi changer en cas de surcharge, info vérifiable en temps réel avec https://tile.openstreetmap.org/cgi-bin/debug les 2 serveurs ok : Yevaud et Vial les 2 serveurs affectés : Scorch et Rhaegal 2 soucis majeurs avec le rendu osm-fr - lors des soucis liés à la maj osm2pgsql, une série de tache automatique ont été désactivées et tout n'est pas encore repris en route, par exemple le rafraîchissement des zoom 1-11 Christian étant en vacances, je suis entrain de voir ce qui reste à faire, une maj des tuiles 1 ä 11 est en cours depuis des heures et cela prendra peut-être encore des heures. donc patience... - il y a qlq abus des tuiles osm-fr ce qui sature régulièrement la file d'attente, provoquant le même problème que décrit ci-dessus avec osm.org la file d'attente du serveur de rendu osm-fr est visible sur http://munin.openstreetmap.fr/osm25.openstreetmap.fr/osm25.openstreetmap.fr/renderd_queue.html ce qui est volontaire et non un bug : - /dirty sur les zoom faible est ultra gourmand en ressource pour éviter que le serveur passe son temps sur ces niveaux, sur osm-fr les /dirty zoom 1 à 11 sont ignoré. osm.org a le même genre de politique (je ne connais pas par cœur le niveau de zoom, c'est peut-être sur le wiki) avec maj le we. Il n'y a donc pas de bug sur le z9 ne montre pas une modif récente. Effacer et recréer les objets posant problème de rendu est contre-productif, cela ne fait que provoquer une expiration et un rendu supplémentaire en perdant au passage l'historique des objets. En espérant avoir été utile et ne pas avoir dit de connerie malgré que je me suis relu :) Cordialement, Marc ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
