Hey,
nachdem wir die ersten Hoods ja produktiv umgestellt haben sollten wir
uns Gedanken über die nächsten Schritte machen. Ich hätte hier folgenden
Vorschlag:
- Hood Budjadingen (2 fastd Instanzen mit jeweils 100 Peers)
- Hood Rastede (1 oder 2 fastd Instanzen mit jeweils 100 Peers)
- Ein VM für 2 Hoods, Lohne und Dinklage - jeder würde hier 100 Peers
bekommen. Die VM könnte auf srv16
Von Budjadingen wird es auch Geld für einen Server geben - das kläre ich
grade mit Matthias Schulz ab.
Eine weitere Hood für Rastede mit 2 fastd Instanzen für 200 Router.
Meinungen oder Einwände?
Die serverseitige Einrichtung würde ich dann wohl erledigen ;)
Stefan
Hi,
ich werde am Montag (morgen) die Supernodes vom Testmaster auf den
Prodkuktivmaster puppet.ffnw.de umziehen. Der Master ist soweit vorbereitet
und getestet.
Falls jemand Einwände hat bitte ich um einen Alternativvorschlag mit Zeitplan
zum Umzug.
Viele Grüße
Clemens
moin,
was passiert eigentlich, wenn man auf nem router automatische _und_
statische Koordinaten einstellt? wäre es nicht sinnvoller, wenn sich im
config mode diese beiden häkchen gegenseitig ausschließen?
lg lorenz
Hi,
ich hab die neue Webseite mal überflogen und nen Haufen issues aufgemacht.
https://git.nordwest.freifunk.net/ffnw/web/issues
Generell sollten die links noch mal alle überprüft werden einige von dehnen sind tot.
Zudem scheinen in der Kategorie -> Firmware -> kompilieren und angrenzende. zitierte Kommandos falsch dar zustellen.
vg
Tarek
Hallo,
wenn ich das richtig verstehe, guck die funktion ja in originator-table
und gibt true zurück, wenn sie irgendwo den string mesh-vpn findet. Aber
wird auch der Wert last-seen berücksichtigt?
beispiel: Knoten hat vpn verbindung, der letzte originator-frame ist
keine 5 sekunden alt. directVPN() -> TRUE. alles io. jetzt verliert der
knoten aus $gründen seine vpn verbindung, aber in der orignator-table
werden immer noch massenweise zeilen gefunden, die den string mesh_vpn
enthalten, aber natürlich nur zombies sind. directVPN() -> TRUE, obwohl
vpn in Wahrheit tot ist.
Oder ist das alles viel einfacher?
lg lrnzo
Hi,
das Gitlab ist nun auf dem aktuellen stabile release (8.8.2). Zudem ist in der git VM das git auf 2.8.3 from source aktualisiert.
Ein sehr nützliches feature was hinzugekommen ist, ist das man nun die build logs im RAW output kriegen kann[0].
Das ist für Fehler Analysen sehr hilfreich.
Hinzu kommt das nun die Architekturen von gluon aus dem soruce generiert werden. Somit werden die Targets dynamisch gebaut.
Kommen also neue Architekturen hinzu selektiert der CI bot diese automatisch.
Zuvor hatte der bot nur auf einen thread compiliert. Nun baut der CI bot ebenfalls dynamisch auf allen logischen cores[1].
nach folgender Formel:
(grep -c processor /proc/cpuinfo)*2
Also Anzahl der logic cores mal zwei. Zweit Prozesse pro logik core.
Referrenz[2].
Aktuell ist es noch nicht möglich mit dem make parameter V=s zu compilieren.
Der generierte log output wird mehre GB groß und überbeansprucht das gitlab somit. Dazu gibt es schon ein issue in gitlab [3].
vg
Tarek
[0] https://git.nordwest.freifunk.net/ffnw-firmware/siteconf/builds/289/raw
[1] https://git.nordwest.freifunk.net/ffnw-firmware/siteconf/builds/289
[2] https://github.com/FreifunkFranken/firmware/blob/master/buildscript#L219
[3] https://gitlab.com/gitlab-org/gitlab-ci/issues/421
Hi,
ich habe mich gerade kurz mit Clemens über das 1.0 Release unterhalten.
Ich hätte hier folgenden Vorschlag:
- Ich habe nun den Ganzen Puppet Code ins Gitlab rübergezogen und fixe
hier noch Kleinigkeiten
- Wir testen alle die Version 1.0 heute oder morgen und signen diese
schon entsprechend
- Am Mittwoch würden wir ein Blogpost veröffentlichen, damit die Nutzer
von dem Großen Update mitbekommen
- Donnerstag im Laufe des Tages würden wir dann den Symlink umschwenken,
sodass die Version verteilt wird
Einwände oder weitere Vorschläge? :)
Viele Grüße
Stefan
Hey zusammen,
ich mache mich ab jetzt daran die Puppet Repos ins Gitlab (sofern dies
funktioniert) umzuziehen und über unseren Puppetmaster zu deployen.
Dann haben wir später im Puppet Board eine Gute Übersicht, welche
Systeme wie deployed wurden.
VG
Stefan
Hi,
ich habe mal ein paar build ENVs auf runner02 gelöscht die in home dirs lagen und älter als 1 1/2 Monate waren. Bitte auchtet darauf wenn im home die gebaut wird sollte das build ENV hinterher aufgeräumt werden. Ansonsten verbraucht es ca. 70GB. Hintergrund ist das mir gerade aufgefallen ist das dem CI bot die platte voll gelaufen ist.
vg
Tarek
Moin,
man kann auf die Mail-Notifications für Issues und Mergerequests
unseres Gitlabs nun auch per Mail antworten.
\o/
grüße
bjo
--
xmpp bjo(a)schafweide.org
