search

freifunk-mwu / technik-meta

Hier werden offene Punkte und Dokus zu Gateway, Software und Netzwerk verwaltet
5 stars 9 forks source link

Wie werden Images gebaut? #4

Closed spookey closed 10 years ago

spookey commented 10 years ago

Bevor wir Issue #2 lösen können müssen wir die Frage des Imagebauens klären:

Momentan bauen wir einmal nachts direkt aus den Quellen die Bleeding-Edge Variante. Nur wenn die Gluon-Jungs einen Versionssprung wagen haben wir also ein Stable Release.

In der Readme zu Gluon findet sich dazu:

Please refrain from using the master branch for anything else but development purposes! Use the most recent release instead. You can list all relaseses by running git branch -a and switch to one by running git checkout v2014.3;make update.

If you're using the autoupdater, do not autoupdate nodes with anything but releases. If you upgrade using random master commits the nodes will break eventually.

Wir setzen also unsere Nodes in Gefahr!!1! :scream_cat: (zumindest gehen wir täglich das Risiko ein mit einem fehlerhaften Update Nodes im Netz zu verlieren).

Was heißt das nun für uns? Ich sehe mehrere Optionen:

Weiterhin ist mir unklar wieso wir drei Branches benötigen ~ Wenn, dann sollte man Stable-Releases auch nur aus den Tags bauen, Beta-Releases nur aus bestimmten Commits und Nightly-Releases täglich. - Bei uns entwickelt keiner an Gluon, ist eine Stable mal fertig, braucht man ja keine Updates bis sich am Backend was ändert.

kokel commented 10 years ago

Ein Vorschlag von mir:

Hierfür wäre es nett, wenn ffctl builder jede Nacht einmal den Satz Images für den branch experimental baut. Darüber hinaus aber auch automatisch bei Bedarf den Satz Images für beta/stable. Z.B. wenn sich was an der site.conf geändert hat

spookey commented 10 years ago

Jow, nicht schlecht.

Wenn beta == stable, dann brauchen wir auch nicht zwei Branches ~ würde dann Beta kicken und nach folgender Regel bauen:

Master > experimental Git-Tag > stable

Immer wenn es Änderungen in der siteconf gibt, beide branches. Bei Änderungen nur in Gluon nur experimental.

Ein Problem bleibt noch - Wenn wir in die Experimental z.B. eine neue Batman-Version reinkonfigurieren, dann bringt uns das nichts, ohne das Backend nachzuziehen.

Wir brauchen ein Testnetz?

kokel commented 10 years ago

Ich bin dafür beta trotzdem zu behalten. Denn das erlaubt uns neue gluon stable Versionen vorher zu testen bzw. über eine beta Phase einzuführen. Ansonsten müssten wir sie ungetestet in die Masse treten.

Zu dem Testnetz: Wär auf jeden Fall cool. Eine batman_adv Version, die mit der aktuellen compat 15 nicht abwärtskompatibel ist, wird es in absehbarer Zeit nicht geben. Ja, man weiß nie, aber das sollen die Entwickler gesagt haben. Soll heißen, wir werden auch aktuellere batman_adv Versionen mit dem produktiv Backend testen können, vorausgesetzt die gluon Jungs patchen die zurück nach barrier breaker, denn ansonsten wird es erst bei dem nächsten owrt release eine neue batman_adv Version geben.

ka-ba commented 10 years ago

Hi! Ganz ehrlich: ich (persönlich) sehe keinen Bedarf für nightlies. Wir wollen in relativ stabiler Form das nutzen, was die Lübecker für uns (und sich und andere) zusammenzimmern. Müssen wir da irgentwelche nodes an der bleeding edge haben? Anders herum: ich würde mal vermuten, dass wir für die stable (und dann konsequenterweise auch für die beta) immer wieder tags der Lübecker auslassen werden, wenn wir keinen Mehrwert bei deren Einsatz bei uns erkennen können. Oder bin ich da auf'm falschen Dampfer?

Auf der anderen Seite: wenn es natürlich genügend Tester bei uns gibt, die unbedingt die allerneuesten nightlies haben wollen, spricht auch wieder nichts dagagen - außer dem Aufwand. Ich würde die nightlies nicht als Prio1 sehen.

Aber aus dem Thema Images will ich mich ja im Grunde raushalten. Ich hatte lediglich angekündigt, vorlaute Kommentare abzugeben; was ich hiermit getan habe. ;} Nix für ungut - just my €.02 ...

spookey commented 10 years ago

Hallo, vielen Dank für die Anregungen. Ich denke gerade an folgendes Schema:

Batman war nur ein Beispiel, es kann uns immer passieren, dass eine Gluon-Entwicklung mit unserer Infrastruktur zusammenpasst. Deshalb sollten wir ein Testnetz pflegen, dass immer versucht der Entwicklung nachzuziehen. Bei Release werden halt die Produktiv-Gateways nachgezogen.

Dies wäre (~ funktioniert auch nur im Testnetz (gateways in site.conf vorm Build umschreiben ?)): Gluon-Master (siteconf-Master) > experimental

Etwas anders schaut es wohl mit unseren eigenen Paketen (OpenWRT Modules gluon-plus.git aus):

Wenn man für die Nodes Software entwickelt, kann es einem ebenso passieren dass in Gluon die Schnitstellen geändert wurden, und alles nichtmehr zusammenpasst. Zum Testen der Software bis zum Merge in Stable:

Gluon Git-Tag (siteconf-Master) > beta

Stable Images mit funktionierender Software dann so:

Gluon Git-Tag (siteconf Git-Tag) > stable

knirps99 commented 10 years ago

Hey,

wann brauchen wir wirklich neue Images ? Ich sehe da 2 Fälle:

Unser stable Release: Da würde ich mich an die Empfehlungen der Gluon Entwickler halten und deren Realeses verwenden. Das heist wir müssen vermutlich 4x im Jahr ein stable Release bauen auf funktionsfähigkeit Prüfen und signieren, welches dann auch per autoupdater in der default Einstellung auf die Nodes geladen wird. Hierfür sollte per ffctl kein automatisches Signierung stattfinden, sa die Mitglieder der Technikgruppe nach Testem des Release das Manifest lokal unterzeichnen sollten, sonst hat die Signierung auch keinerlei Aussagekraft.

Unser experimental = beta Release: Diese wird nightly von ffctl gebaut und signiert. Stellt jemand seinen Autoupdater absichtlich auf experimental um, so muss er sich bewust sein das dies seinen Router bricken kann bzw eventuell kein Zugang mehr zum Gluon netz da ist. Diese sollten auch ganz normal bei uns im Produktiv netz mitlaufen.

Wir werden sowieso nicht verhindern können, dass wir in ein paar Monaten nach Release eine bunte Mischung aus verschiedenen Firmwareversionen von uns (nicht alle werden den Autoupdater benutzen wollen), und selbstgebauten Konstruktionen (selbst konfigurierten X86 maschinen, selbstcompilte Openwrts, VMs) etc. im Netz haben. Ich sehe diese auch als sehr Wichtig an, da wir Freifunk machen und jeder mit den Zutaten batman-adv und fastd Zugang zu unserem Netz haben sollte ! Das dabei eventuell mal was schief geht und unser Netz dabei in Mitleidenschaft gezogen wird, sollten wir dabei in Kauf nehmen.

Für das Testnetz an sich sollten wir keine fertigen Images anbieten. Diese sollten von der Technik Gruppe bei Bedarf gebaut werden um auch mal Experimente, die mit Sicherheit das Netz kaputt machen, durchführen zu können. Auch eine Signierung dieser Images kann, wenn nötig (=testen von Autoupdater Features), von Hand durchgeführt werden. Sonst haben wir im Testnetz sehr schnell End-User drin, die bleeding edge sein möchten.

Ich sehe da keine großen Probleme mehr, und sehe auch nicht den Bedarf einer großartigen Automatisierung vor dem Release. Die paar stable Images welche wir jährlich rausbringen, können auf einer kontrollierten Build Umgebung (z.B. VM von Lukas) gebaut werden und das Manifest per Hand von n Leuten aus der Technikgruppe signiert werden, bevor das ganze per Autoupdater rausgehauen wird.

Die nightly Builds sehe ich eher als Extra für Leute die unbedingt bei der Gluon Entwicklung bleeding edge sein wollen. Wenn diese automatisch gebaut werden und automatisch von der Buildumgebung signiert werden, damit sie per Autoupdater verteilt werden, ist das ein nettes Feature von uns was allerdings nicht unser erstes stable release verzögern sollte. Die meisten Leute die diese nightlys einsetzen wollen, werden auch eher unsere site.conf herunterladen und selber builden weil sie gerne noch paket x und feature y in ihrer Freifunk Firmware hätten.

0,02€

kokel commented 10 years ago

0,02€? Haha ;-)

Nochmal zur Klarstellung:

nightly (alt) == experimental (neu) -> Benamung analog zu anderen Communities

Spookeys Vorschlag der Git-Tag Zuordnung finde ich sehr gut. M.m. nach sollten wir das so machen.

Wer wann welches Image nimmt, was für Kuriositäten wir später evtl. Im Netz haben werden, wer seinen autoupdater wie einstellt, steht auf einem anderen Blatt. Das können wir hier nicht lösen.

BTW: Wir können frühestens mit der nächsten Gluon Stable Version stable gehen, da batman_adv compat 15 lediglich im gluon master bereitsteht.

kokel commented 10 years ago

Ich fasse nochmal zusammen:

stable -> gluon stable release (tag) + site.conf/site.mk tag

beta -> gluon stable release (tag) + site.conf/site.mk master

experimental -> gluon master branch + site.conf/site.mk master

spookey commented 10 years ago

Dieses Ticket zielte darauf ab, mir input zu geben, wie ich den Gluon-Firmware Builder im Groben zu konzipieren habe.

Es kamen hier sehr gute Gedankengänge zusammen - vielen Dank.

Meine Fragen sind vorerst beantwortet, Ticket wird geschlossen, Gluon Builder folgt.