<div dir="ltr">Non je ne parle pas de l'installation du socle logiciel.Le problème c'est bien la réplication des données et là on est vraiment à la ramasse: il suffit de voir comment c'est compliqué et long de redémarrer quand une instance est plantée, et pas du tout à cause du logiciel opensource utilisé ou de l'OS.<div><br></div><div>On a un problème sérieux dans l'architecture des données elles-mêmes et leur mode de distribution/réplication. Et on n'a pratiquement rien fait pour améliorer ça.</div></div><div class="gmail_extra"><br><div class="gmail_quote">Le 23 juillet 2017 à 19:59, marc marc <span dir="ltr"><<a href="mailto:marc_marc_irc@hotmail.com" target="_blank">marc_marc_irc@hotmail.com</a>></span> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Philippe je me perd dans la structure de ton message.<br>
<br>
ma réponse si j'ai bien compris ton avis :<br>
- la doc d'installation d'un overpass api est limpide pour un sysadmin<br>
(même si je ne l'ai pas encore testé). jesaispluski a fait un ansile.<br>
il ne reste qu'à valider mais si c'est confirmé, déployer une nouvelle<br>
instance n'est qu'une question d'avoir un serveur pour l'héberger et des<br>
humains qui s'en occupent...<br>
Passer à du propriétaire ne change rien à ces 2 besoins.<br>
Au contraire ca implique de changer l'existant.<br>
<br>
- la majorité des énormes site mondiaux tournent sur un socle open<br>
source. Tous les besoins que tu décris existent en open source et sont<br>
massivement utilisé.<br>
Changer de roue (le logiciel) ne résout rien.<br>
<br>
- avoir un opendata en logiciel propriétaire signifie que tu ne peux pas<br>
la répliquer pour tel ou tel projet sans devoir faire appel à du<br>
propriétaire... souvent payant...<br>
Avoir une roue payante ne résout rien.<br>
<br>
Le 23. 07. 17 à 19:00, Philippe Verdy a écrit :<br>
<div><div class="h5">> Je crois que le gros problème pour avoir plus de serveurs et donc de<br>
> redondance c'est toujours le même: moins un problème de bande passante<br>
> que de la charge énorme que représente l'installation de la base de<br>
> données, et le fait que très peu de progrès ont été faits pour faciliter<br>
> sa réplication.<br>
><br>
> Les diffs ne sont pas forcément la meilleure façon si on peut disposer<br>
> de réplication directe entre bases de données. Mais le choix initial de<br>
> Postgres ne facilite pas les choses, et là où ça marche vraiment très<br>
> bien c'est sur d'autres moteurs, malheureusement "propriétaires" comme<br>
> Oracle, mais en fait seulement commerciaux et qui pourtant ne devrait<br>
> pas coûter très cher en licence en comparaison des coûts nécessaires<br>
> pour les stockages, l'hébergement dans un datacenter et la bande<br>
> passante, mais surtout les couts humains que représentent la maintenance<br>
> sur la solution actuelle.<br>
><br>
> Passer à des moteurs SQL commerciaux plus solides est surtout un seuil<br>
> psychologique pour les promoteurs du projet. On craint une nouvelle<br>
> dépendance alors que les dépendances les plus importantes (humaines) ne<br>
> sont même pas résolues. On en arrive alors à figer les évolutions, et le<br>
> projet est soutenu par une infrastructure de plus en plus fragile, qu'un<br>
> rien suffirait à faire s'effondrer du jour au lendemain (avec des pannes<br>
> qui mettront ensuite le projet en péril pendant des mois, avec de<br>
> grosses difficultés pour recapter l'audience qu'il avait).<br>
><br>
> On promeut OSM auprès des administrations, mais faute de ressources<br>
> humaines on n'est crédible que si à côté de nous on a de vrais<br>
> fournisseurs de services professionnels. Ces fournisseurs existent, on<br>
> les a incité à utiliser nos données mais on les a trop peu sollicité<br>
> pour qu'ils continuent aussi à solidifier l'infrastructure (quitte à<br>
> accepter qu'on y incorpore des composants propriétaires qui seraient<br>
> transparents pour nous et pas gênants du tout car n'affectant pas les<br>
> données elles-mêmes, mais juste l'infrastructure qui les supporte).<br>
><br>
> Et tant qu'on ne franchit pas ce seuil psychologique, Google a encore de<br>
> beaux jours devant lui et continuera à imposer ses services (mais avec<br>
> en revanche un comportement pas transparent du tout, affectant les<br>
> données directement, et avec l'accaparement des droits sur ces données,<br>
> leur disponibilité et les conditions de leur réutilisations, qui ne font<br>
> que devenir de plus en plus restrictives et chères pour tout le monde)<br>
><br>
> Demandons nous ce qui est important pour OSM: le logiciel qui le<br>
> supporte est-il si indispensable et non remplaçable ? Ou bien est-ce les<br>
> données ? Ne fermons pas la porte aux logiciels propriétaires dans<br>
> l'infrastructure. A la place consolidons les API, formats de données.<br>
><br>
> Là des choses sont à expérimenter, pas forcément uniquement au sein du<br>
> moteur SQL, mais avec des systèmes de fichiers synchronisés au niveau de<br>
> l'OS, ou avec les moniteurs transactionnels. ou la réplication dynamique<br>
> de machines virtuelles contenant une instance d'OS entière avec ses<br>
> logiciels et données.<br>
><br>
> Le 23 juillet 2017 à 16:28, sly (sylvain letuffe) <<a href="mailto:liste2@letuffe.org">liste2@letuffe.org</a><br>
</div></div>> <mailto:<a href="mailto:liste2@letuffe.org">liste2@letuffe.org</a>>> a écrit :<br>
<span class="im HOEnZb">><br>
> overflorian wrote<br>
> > Est-ce que vous sauriez à quoi cela est dû ?<br>
><br>
> Cette page liste l'historique des problèmes rencontrés par les 2<br>
> instances<br>
> "principales" :<br>
> <a href="https://wiki.openstreetmap.org/wiki/Overpass_API/status" rel="noreferrer" target="_blank">https://wiki.openstreetmap.<wbr>org/wiki/Overpass_API/status</a><br>
> <<a href="https://wiki.openstreetmap.org/wiki/Overpass_API/status" rel="noreferrer" target="_blank">https://wiki.openstreetmap.<wbr>org/wiki/Overpass_API/status</a>><br>
><br>
><br>
> overflorian wrote<br>
> > Quelles en sont les causes profondes ?<br>
><br>
> Je pense que ça se résume simplement :<br>
> - Trop de gens tirent dessus et trop peu de gens installent d'instances<br>
> publiques (pour répartir la charge, offrir une possibilité de<br>
> redondance) ou<br>
> participent à la maintenance.<br>
><br>
><br>
><br>
</span><div class="HOEnZb"><div class="h5">> ______________________________<wbr>_________________<br>
> Talk-fr mailing list<br>
> <a href="mailto:Talk-fr@openstreetmap.org">Talk-fr@openstreetmap.org</a><br>
> <a href="https://lists.openstreetmap.org/listinfo/talk-fr" rel="noreferrer" target="_blank">https://lists.openstreetmap.<wbr>org/listinfo/talk-fr</a><br>
><br>
<br>
______________________________<wbr>_________________<br>
Talk-fr mailing list<br>
<a href="mailto:Talk-fr@openstreetmap.org">Talk-fr@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-fr" rel="noreferrer" target="_blank">https://lists.openstreetmap.<wbr>org/listinfo/talk-fr</a><br>
</div></div></blockquote></div><br></div>