Diskussion:Förderanträge/umap instanz: Unterschied zwischen den Versionen
Yala (Diskussion | Beiträge) (Beginn der Zusammenfassung der Mailinglistendiskussion) |
(Ich glaube nicht, dass das hier irgendjemand liest.) |
||
| (6 dazwischenliegende Versionen von einem anderen Benutzer werden nicht angezeigt) | |||
| Zeile 5: | Zeile 5: | ||
Im Zuge der Diskussionen auf der Mailingliste stellen sich Fragen zur Ausgestaltung einer uMap Umgebung. Diese sind: | 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. | 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 | 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 [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]. | |||
Weiterführende Links zu dockerisierten uMap Konfigurationen: | |||
-- | * 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) | |||
''Hinweis:'' 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, sowie des Abhängigkeits- und Zustandsmanagements halten. | |||
---- | --[[Benutzer:Yala|Yala]] ([[Benutzer Diskussion:Yala|Diskussion]]) 17:43, 9. Mai 2018 (CEST) | ||
: Ich glaube nicht, dass das hier irgendjemand liest. Warum äußerst du dich nicht auf der Mailingliste? Dort wird diskutiert. --[[Benutzer:Nakaner|Nakaner]] ([[Benutzer Diskussion:Nakaner|Diskussion]]) 19:38, 13. Mai 2018 (CEST) | |||
Aktuelle Version vom 13. Mai 2018, 17:38 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 zu dockerisierten uMap Konfigurationen:
- 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)
Hinweis: 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, sowie des Abhängigkeits- und Zustandsmanagements halten.
--Yala (Diskussion) 17:43, 9. Mai 2018 (CEST)
- Ich glaube nicht, dass das hier irgendjemand liest. Warum äußerst du dich nicht auf der Mailingliste? Dort wird diskutiert. --Nakaner (Diskussion) 19:38, 13. Mai 2018 (CEST)
