andibraeu
commented
5 years ago - alle Einträge werden bei DELETES überprüft: das ist einerseits aus der Not geboren, dass Travis trotzdem läuft und etwas tun will. Das war bisher aber kein großes Problem, DELETES gibt es recht selten und werden meist auch von den Betreibern selbst erstellt
- Monitoring vs. travis: das stimmt schon, Travis wurde nie als Monitoring für die API-Files gedacht, sondern nur als eine Hilfe, ob Communityfiles zum Zeitpunkt einer Änderung korrekt sind. Anfangs wurden auch immer alle Files geprüft, später habe ich das implementiert, dass nur das Diff geprüft wird.
- etwas Monitoring haben wir unter https://api-viewer.freifunk.net gebaut. @OLeier hatte sich auch schon tiefer damit auseinander gesetzt.
- dein Monitoringansatz finde ich gut, das können wir später, wenn du es für "fertig" oder "fast fertig" hältst auch unter einer Subdomain von freifunk.net stellen. Wenn ihr es trotzdem betreiben könnt wäre das toll, die freifunk.net-Admins betreiben jetzt schon ziemlich viel
- über das automatische Erstellen von delete PRs müssten wir noch detaillierter reden
OLeier
christian-weiss
Ich finde es super, dass Travis-CI jeden PR prüft. Sogar, dass bei neuen lokalen Gruppen (Städten) initial geprüft wird, ob die referenzierte API Datei der lokalen Gruppe ok ist, statt nur die directory.json selbst zu prüfen. Auch ok, ist das die API Datei dieser Community geprüft wird, wenn der directory.json Eintrag (Zeile) sich ändert (z.B. um einen Schreibfehler im Stadtnamen zu korrigieren oder eine neue URL einzutragen).
Aktuell prüft Travis-CI jedoch bei einem Delete gleich alle Einträge der directory.json, was wir m.E. nicht tun sollten!
Wenn eine lokale Gruppe Inserts, Updates oder Deletes per PR einreicht, dann sollten nicht durch QA-Probleme in fremden (referenzierten) API Dateien geblockt werden. Ebenso sollte der Merger nicht gezwungen sein den PR-Merge zu verzögern bis alle fremden APIs wieder ok sind, noch sollte er gezwungen sein den fehlgeschlagenen Build zu ignorieren indem er diesen einfach merged.
Das löschen von Zeilen sollte m.E. jedoch nicht dazu führen (wie aktuell) dass alle API Dateien aller Einträge auf Korrektheit überprüft werden. Denn diese sind bewusst dezentral und damit außerhalb des QA-Prozesses für PRs. Das sollte nicht im Rahmen eines "Build Prozesses", sondern mit einem regelmäßigen und unabhängigen Monitoring erfolgen. Zusätzlich darf natürlich jede lokale Gruppe einen QA-Prozess für die eigene API Datei erstellen, die JSON-Schema Dateien von Freifunk zum validieren des JSON liegen ja öffentlich bereit: https://github.com/freifunk/api.freifunk.net/tree/master/specs
Hilfreich wäre es, wenn man ein sample github repo mit einem entsprechendem .travis.yml bereitstellt - dass würde es den lokalen Gruppen leichter machen diesen, eigenen, unabhngigen Prozess aufzusetzen.
Der Prozess zum "Entfernen von Einträgen in der directory.json" sollte m.E. jetzt etwas formaler werden. Er sollte festlegen, wie lange ein falscher URL / eine ungültige API Datei mindestens und maximal toleriert wird.
Ein Mindestwert ist notwendig, damit bei temporären Verbindungsproblemen der Eintrag nicht direkt entfernt wird und damit die lokale Gruppe erst einen neuen PR stellen müsste (welcher ggf. mehrere Tage benötigt, je nach Verfügbarkeit der Personen).
Es ist also wie in der README.md erwähnt eine Rückfrage an die lokale Gruppe notwendig, um sicherzustellen, dass an dem Problem geabeitet wird und in überschaubarer Zeit eine Lösung gefunden wird. Zitat: "Stark veraltete oder ungültige Dateien werden nach Rückfrage wieder entfernt."
Auf der anderen Seite muss sichergestellt sein, dass die directory.json keine große Anzahl an ungültigen Endpunkten auflistet (nicht erreichbare Endpunkte: DNS Einstellungen falsch, URL falsch, Zertifikat abgelaufen/falsch, JSON ungültig, etc.) - es ist also notwendig, dass es einen Maximalwert gibt, der definiert, wie lange man auf eine Lösung wartet, bevor man den Eintrag löscht. Ich persönlich halte 1 Woche für ausreichend lang, da ich erwarte, dass lokale Gruppen aus mehreren Personen bestehen und eine Urlaubsvertretung organisiert wird und Wissenstransfer stattfindet. Zudem kann man im Projekt sicher auch kurzfristig Hilfe bekommen. Wer das nicht sicherstellen kann ist vielleich einfach eine zu kleine lokale Gruppe um sich als Gruppe hier einzutragen (one-man-show).
Da für eine solche Rücksprache Kontaktdaten benötigt werden ist aktuell ein "Rückfrage Prozess" aktuell schwer umzusetzen - die API-Datei kann ja offline sein, wodurch dann keine Kontaktdaten direkt vorliegen. Man muss die Leute kennen oder per Webrecherche / Herumfragen versuchen herauszufinden, wer eine Lösung herbeiführen kann / verantwortlich für die API Datei ist. Das ist zeitaufwändig und bindet unnötig Ressoucen (z.B. des Mergers) die in eine Weiterentwicklung des Projektes sinnvoller investiert wären. Das o.g. Monitoring sollte also die letzte, gültige Version der API Datei cachen oder wir sollten einen API Verantwortlichen in das Schema der directory.json aufnehmen. Von Letzterem rate ich ab, da sowas häufig nicht gepflegt wird (es müsste jedes mal ein PR vorausgehen).
O.g. Monitoring entsteht zur Zeit hier: http://community-registry.ff-hamm.de/ Dieser Report ist ein Alpha-Preview, wird noch nicht stündlich aktualisiert, und noch nicht alle Werte sind dynamisch ermittelt (Implementierung findet aktuell statt und wird noch detailierter und wird auch Optimierungstips geben).
Jede lokale Gruppe soll dort die Möglichkeit bekommen ein Alerting (E-Mail Report), basierend auf den Kontaktdaten aus der API Datei (gecachte letzte Version) zu aktivieren. Gerne kann ich auch die Erstellung von "Delete PRs" in https://github.com/freifunk/directory.api.freifunk.net per github API implementieren, wenn, z.B. das Problem nach dem Mindestwert (z.B. 7 Tagen) nicht behoben ist (unabhängig davon, ob ein Alert aktiviert wurde oder nicht). Der Source Code wird natürlich noch auf github.com veröffentlicht. Mittelfristig würde ich es begrüßen diesen in eine Subdomain von freifunk.net zu installieren und eine Übergabe an die Admins von freifunk.net zu machen, um die langfristige Verfügbarkeit sicherzustellen.
Ich freue mich auf Euer Feedback zu diesem Prozessvorschlag und zum o.g. Monitoring Tool.