[OSM-talk-fr] Sécuriser Overpass API : quelles solutions ?

[Philippe Verdy]

Je crois que le gros problème pour avoir plus de serveurs et donc de
redondance c'est toujours le même: moins un problème de bande passante que
de la charge énorme que représente l'installation de la base de données, et
le fait que très peu de progrès ont été faits pour faciliter sa réplication.

Les diffs ne sont pas forcément la meilleure façon si on peut disposer de
réplication directe entre bases de données. Mais le choix initial de
Postgres ne facilite pas les choses, et là où ça marche vraiment très bien
c'est sur d'autres moteurs, malheureusement "propriétaires" comme Oracle,
mais en fait seulement commerciaux et qui pourtant ne devrait pas coûter
très cher en licence en comparaison des coûts nécessaires pour les
stockages, l'hébergement dans un datacenter et la bande passante, mais
surtout les couts humains que représentent la maintenance sur la solution
actuelle.

Passer à des moteurs SQL commerciaux plus solides est surtout un seuil
psychologique pour les promoteurs du projet. On craint une nouvelle
dépendance alors que les dépendances les plus importantes (humaines) ne
sont même pas résolues. On en arrive alors à figer les évolutions, et le
projet est soutenu par une infrastructure de plus en plus fragile, qu'un
rien suffirait à faire s'effondrer du jour au lendemain (avec des pannes
qui mettront ensuite le projet en péril pendant des mois, avec de grosses
difficultés pour recapter l'audience qu'il avait).

On promeut OSM auprès des administrations, mais faute de ressources
humaines on n'est crédible que si à côté de nous on a de vrais fournisseurs
de services professionnels. Ces fournisseurs existent, on les a incité à
utiliser nos données mais on les a trop peu sollicité pour qu'ils
continuent aussi à solidifier l'infrastructure (quitte à accepter qu'on y
incorpore des composants propriétaires qui seraient transparents pour nous
et pas gênants du tout car n'affectant pas les données elles-mêmes, mais
juste l'infrastructure qui les supporte).

Et tant qu'on ne franchit pas ce seuil psychologique, Google a encore de
beaux jours devant lui et continuera à imposer ses services (mais avec en
revanche un comportement pas transparent du tout, affectant les données
directement, et avec l'accaparement des droits sur ces données, leur
disponibilité et les conditions de leur réutilisations, qui ne font que
devenir de plus en plus restrictives et chères pour tout le monde)

Demandons nous ce qui est important pour OSM: le logiciel qui le supporte
est-il si indispensable et non remplaçable ? Ou bien est-ce les données ?
Ne fermons pas la porte aux logiciels propriétaires dans l'infrastructure.
A la place consolidons les API, formats de données.

Là des choses sont à expérimenter, pas forcément uniquement au sein du
moteur SQL, mais avec des systèmes de fichiers synchronisés au niveau de
l'OS, ou avec les moniteurs transactionnels. ou la réplication dynamique de
machines virtuelles contenant une instance d'OS entière avec ses logiciels
et données.

Le 23 juillet 2017 à 16:28, sly (sylvain letuffe) <liste2 at letuffe.org> a
écrit :

> overflorian wrote
> > Est-ce que vous sauriez à quoi cela est dû ?
>
> Cette page liste l'historique des problèmes rencontrés  par les 2 instances
> "principales" :
> https://wiki.openstreetmap.org/wiki/Overpass_API/status
>
>
> overflorian wrote
> > Quelles en sont les causes profondes ?
>
> Je pense que ça se résume simplement :
> - Trop de gens tirent dessus et trop peu de gens installent d'instances
> publiques (pour répartir la charge, offrir une possibilité de redondance)
> ou
> participent à la maintenance.
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20170723/ba30c9b5/attachment.htm>