Diskussion:Förderanträge/umap instanz: Unterschied zwischen den Versionen
Yala (Diskussion | Beiträge) K (Liste in der Mail war nur von der Wikiseite kopiert.) |
Yala (Diskussion | Beiträge) K (Antwort von Yohan im GitHub issue) |
||
| Zeile 13: | Zeile 13: | ||
Die französische Instanz von uMap leidet unter Geschwindigkeitseinbußen. Die Frage wäre, ob es besser sein könnte mit Upstream zu kooperieren und gemeinsam eine große Instanz zu optimieren. - https://github.com/umap-project/umap/issues/578 | Die französische Instanz von uMap leidet unter Geschwindigkeitseinbußen. Die Frage wäre, ob es besser sein könnte mit Upstream zu kooperieren und gemeinsam eine große Instanz zu optimieren. - https://github.com/umap-project/umap/issues/578 | ||
Wir | * Die Antwort tendiert bislang eher dazu, lieber unabhängige Wege zu gehen. | ||
Wir könnten dann auch darüber sprechen mit den hiesigen Anforderungen an der uMap Entwicklung teilzunehmen, bezogen darauf wie sich das Systemdesign mit asnychron operierende Modulen (Twisted?) aufspalten ließe, um horizontale Skalierbarkeit zu erreichen. Dies wäre vermutlich auch hilfreich im Hinblick auf [https://github.com/umap-project/umap/issues/468 konkurrierende Echtzeitbearbeitung]. Als ersten Ansatz für verteilt funktionierendes uMap gibt es Meldungen von Instanzen, die erfolgreich Master-Slave Replikation betreiben und mehrere nur-lesen Endpunkte gestatten. Schreiben wäre in diesem Szenario auf eine begrenzt. | |||
Im OSM Wiki gibt es eine [https://wiki.openstreetmap.org/wiki/UMap#Instances Liste weiterer uMap Instanzen]. | Im OSM Wiki gibt es eine [https://wiki.openstreetmap.org/wiki/UMap#Instances Liste weiterer uMap Instanzen]. | ||
Version vom 9. Mai 2018, 16:01 Uhr
Im Zuge der Diskussionen auf der Mailingliste stellen sich Fragen zur Ausgestaltung einer uMap Umgebung. Diese sind:
- Auf welchem Server soll die Instanz laufen?
Hierfür sind die Sonderbestimmungen Serverkostenförderung, v.a. ihr letzter Punkt, zu beachten. Dies könnte bedeuten eine uMap Instanz im Kontext des gesamten FOSSGIS Infrastruktur zu betrachten.
- Inwiefern soll mit Upstream kooperiert werden?
Die französische Instanz von uMap leidet unter Geschwindigkeitseinbußen. Die Frage wäre, ob es besser sein könnte mit Upstream zu kooperieren und gemeinsam eine große Instanz zu optimieren. - https://github.com/umap-project/umap/issues/578
- Die Antwort tendiert bislang eher dazu, lieber unabhängige Wege zu gehen.
Wir könnten dann auch darüber sprechen mit den hiesigen Anforderungen an der uMap Entwicklung teilzunehmen, bezogen darauf wie sich das Systemdesign mit asnychron operierende Modulen (Twisted?) aufspalten ließe, um horizontale Skalierbarkeit zu erreichen. Dies wäre vermutlich auch hilfreich im Hinblick auf konkurrierende Echtzeitbearbeitung. Als ersten Ansatz für verteilt funktionierendes uMap gibt es Meldungen von Instanzen, die erfolgreich Master-Slave Replikation betreiben und mehrere nur-lesen Endpunkte gestatten. Schreiben wäre in diesem Szenario auf eine begrenzt.
Im OSM Wiki gibt es eine Liste weiterer uMap Instanzen.
Weiterführende Links sind außerdem:
- https://github.com/umap-project/umap/issues/80
- https://github.com/jezdez/umap-dokku (für Entwicklungsumgebungen)
- https://github.com/umap-project/umap/pull/456 (für Produktivumgebungen)
Bei Ecobytes setzen wir libre.sh (Docker Compose) und Dokku (Heroku-style git push releases) ein, was wir für eine bequeme Methode der Prozessisolation halten.
--Yala (Diskussion) 17:43, 9. Mai 2018 (CEST)
