Hi, ich möchte gerne mal eure Meinung zum Thema partielle Updates hören. Der Kerngedanke dahinter ist, ein fertiges Firmwareupdate zunächst nur in einer einzigen Hood auszurollen. Läuft dieses Update ohne Verluste, wird das Update in weiteren Hoods nachgezogen bis alle Hoods geupdated sind. Das muss gar nicht unser Standardprozess werden. Aber ich möchte das mal als Möglichkeit für besonders kritische Updates wie bspw. das 802.11s-Update vorschlagen. Was meint ihr? Vllt. hat sogar jemand Ideen zur Realisierung. Viele Grüße Clemens
Hallo Clemens, sehr gute Idee - ich hätte da mit Tarek schon einmal drüber gesprochen. Im Endeffekt können wir das Update kontrolliert freigeben: jeder Router meldet sich mit einer Hood spezifischen v6 Adresse beim Mirror. Wir können dort via simplen Bash Script bestimmte Hoods in einem FW Ordner leiten. Von meinem iPhone gesendet
Am 13.10.2017 um 15:54 schrieb Clemens John via Dev <dev@lists.ffnw.de>:
Hi,
ich möchte gerne mal eure Meinung zum Thema partielle Updates hören. Der Kerngedanke dahinter ist, ein fertiges Firmwareupdate zunächst nur in einer einzigen Hood auszurollen. Läuft dieses Update ohne Verluste, wird das Update in weiteren Hoods nachgezogen bis alle Hoods geupdated sind.
Das muss gar nicht unser Standardprozess werden. Aber ich möchte das mal als Möglichkeit für besonders kritische Updates wie bspw. das 802.11s-Update vorschlagen.
Was meint ihr? Vllt. hat sogar jemand Ideen zur Realisierung.
Viele Grüße Clemens _______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
On 10/13/17 19:17, Stefan Dunkel via Dev wrote:
Hallo Clemens,
sehr gute Idee - ich hätte da mit Tarek schon einmal drüber gesprochen.
Im Endeffekt können wir das Update kontrolliert freigeben: jeder Router meldet sich mit einer Hood spezifischen v6 Adresse beim Mirror. Wir können dort via simplen Bash Script bestimmte Hoods in einem FW Ordner leiten.
ich möchte gerne mal eure Meinung zum Thema partielle Updates hören. Der Kerngedanke dahinter ist, ein fertiges Firmwareupdate zunächst nur in einer einzigen Hood auszurollen. Läuft dieses Update ohne Verluste, wird das Update in weiteren Hoods nachgezogen bis alle Hoods geupdated sind.
Das muss gar nicht unser Standardprozess werden. Aber ich möchte das mal als Möglichkeit für besonders kritische Updates wie bspw. das 802.11s-Update vorschlagen.
Ich würde vorschlagen das wir immer die kleinste hood als Vorreiter nehmen und wie du es schon gesagt hattest muss das nicht unser Standard Prozess werden. vg Tarek
Jap, das wäre das sinnvollere Von meinem iPhone gesendet
Am 14.10.2017 um 10:54 schrieb Jan-Tarek Butt via Dev <dev@lists.ffnw.de>:
On 10/13/17 19:17, Stefan Dunkel via Dev wrote: Hallo Clemens,
sehr gute Idee - ich hätte da mit Tarek schon einmal drüber gesprochen.
Im Endeffekt können wir das Update kontrolliert freigeben: jeder Router meldet sich mit einer Hood spezifischen v6 Adresse beim Mirror. Wir können dort via simplen Bash Script bestimmte Hoods in einem FW Ordner leiten.
ich möchte gerne mal eure Meinung zum Thema partielle Updates hören. Der Kerngedanke dahinter ist, ein fertiges Firmwareupdate zunächst nur in einer einzigen Hood auszurollen. Läuft dieses Update ohne Verluste, wird das Update in weiteren Hoods nachgezogen bis alle Hoods geupdated sind.
Das muss gar nicht unser Standardprozess werden. Aber ich möchte das mal als Möglichkeit für besonders kritische Updates wie bspw. das 802.11s-Update vorschlagen.
Ich würde vorschlagen das wir immer die kleinste hood als Vorreiter nehmen und wie du es schon gesagt hattest muss das nicht unser Standard Prozess werden.
vg Tarek
_______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Hi, es gibt doch Router die den Autoupdater auf Testing stehen haben... das wäre doch eine Gute Möglichkeit, so kann keiner ungewollt Versuchskaninchen werden... lg Malte Am 14.10.2017 um 11:19 schrieb Stefan Dunkel via Dev:
Jap, das wäre das sinnvollere
Von meinem iPhone gesendet
Am 14.10.2017 um 10:54 schrieb Jan-Tarek Butt via Dev <dev@lists.ffnw.de>:
On 10/13/17 19:17, Stefan Dunkel via Dev wrote: Hallo Clemens,
sehr gute Idee - ich hätte da mit Tarek schon einmal drüber gesprochen.
Im Endeffekt können wir das Update kontrolliert freigeben: jeder Router meldet sich mit einer Hood spezifischen v6 Adresse beim Mirror. Wir können dort via simplen Bash Script bestimmte Hoods in einem FW Ordner leiten.
ich möchte gerne mal eure Meinung zum Thema partielle Updates hören. Der Kerngedanke dahinter ist, ein fertiges Firmwareupdate zunächst nur in einer einzigen Hood auszurollen. Läuft dieses Update ohne Verluste, wird das Update in weiteren Hoods nachgezogen bis alle Hoods geupdated sind.
Das muss gar nicht unser Standardprozess werden. Aber ich möchte das mal als Möglichkeit für besonders kritische Updates wie bspw. das 802.11s-Update vorschlagen.
Ich würde vorschlagen das wir immer die kleinste hood als Vorreiter nehmen und wie du es schon gesagt hattest muss das nicht unser Standard Prozess werden.
vg Tarek
_______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
_______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
On 10/16/17 19:07, Malte Modler via Dev wrote:
Hi,
es gibt doch Router die den Autoupdater auf Testing stehen haben... das wäre doch eine Gute Möglichkeit, so kann keiner ungewollt Versuchskaninchen werden...
Wir haben das natürlich bereits entsprechend mit testing Images getestet. Es geht im Grunde generell darum wie wir bei einem kritischen update, der das Netz unwiderruflich lahmlegen kann, vorgehen. Und da kam die Idee mit dem hoodweisen update. Um im worst case nicht alle Router auf einmal zu schrotten. vg :) Tarek
es gibt von Sem dazu das Angebot, ein gewerbegebiet bei Lohne als testhood zu definieren. Mit echten Routern drin. :) Koordinaten kommen noch. werde dann einen MR dazu vorbereiten. LG lorenz Am 16.10.2017 um 20:27 schrieb Jan-Tarek Butt via Dev:
On 10/16/17 19:07, Malte Modler via Dev wrote:
Hi,
es gibt doch Router die den Autoupdater auf Testing stehen haben... das wäre doch eine Gute Möglichkeit, so kann keiner ungewollt Versuchskaninchen werden...
Wir haben das natürlich bereits entsprechend mit testing Images getestet.
Es geht im Grunde generell darum wie wir bei einem kritischen update, der das Netz unwiderruflich lahmlegen kann, vorgehen. Und da kam die Idee mit dem hoodweisen update. Um im worst case nicht alle Router auf einmal zu schrotten.
vg :) Tarek
_______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
siehe https://git.ffnw.de/ffnw-firmware/packages/merge_requests/76 Am 16.10.2017 um 20:35 schrieb lrnzo via Dev:
es gibt von Sem dazu das Angebot, ein gewerbegebiet bei Lohne als testhood zu definieren. Mit echten Routern drin. :) Koordinaten kommen noch. werde dann einen MR dazu vorbereiten.
LG lorenz
Am 16.10.2017 um 20:27 schrieb Jan-Tarek Butt via Dev:
On 10/16/17 19:07, Malte Modler via Dev wrote:
Hi,
es gibt doch Router die den Autoupdater auf Testing stehen haben... das wäre doch eine Gute Möglichkeit, so kann keiner ungewollt Versuchskaninchen werden...
Wir haben das natürlich bereits entsprechend mit testing Images getestet.
Es geht im Grunde generell darum wie wir bei einem kritischen update, der das Netz unwiderruflich lahmlegen kann, vorgehen. Und da kam die Idee mit dem hoodweisen update. Um im worst case nicht alle Router auf einmal zu schrotten.
vg :) Tarek
_______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
_______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
On 10/16/17 23:25, lrnzo via Dev wrote:
siehe https://git.ffnw.de/ffnw-firmware/packages/merge_requests/76
Wir bräuchten hier für noch entsprechend eine test Umgebung in Server Bereich. Haben wir irgendwo noch platz ne VM für die test hood unterzubringen. Ich weiß das srv14 als test ENV diente, allerdings würde Clemens die gerne aus der Buchhaltung loswerden wollen, daher würde ich die für diesen Zweck ausschließen. Schöne Grüße Tarek
participants (5)
-
Clemens John -
Jan-Tarek Butt -
lrnzo -
Malte Modler -
Stefan Dunkel