Der Knoten hat sich soeben die richtige Firmware gezogen, hat (warum auch immer) einige Tage gedauert.
Ist seit ~ 3 Tagen in Domäne 04.
Da ist noch einer … und dieser weigert sich offenbar beständig … Liegen denn für Warendorf jetzt auch an der richtigen Stelle die richtigen Images?
1 „Gefällt mir“
Sind jetzt beide im Updater-Prozess.
Jo, da sind wir dran. Die haben Hardware, die nicht mit v2015.1.2 lief und spezielle Images braucht. Das werden wir jetzt bald umstellen, da der forcedeth-Treiber in 2016.1 regulär enthalten ist.
Ich habe mal ein wenig in den Logfiles des Firmware-Servers gewühlt um den zeitlichen Verlauf der Knotenmigration visualisieren zu können. Ich habe mir alle Zeilen geben lassen, die folgende Bedingungen erfüllten:
- IP Adresse beginnt mit
2a03:2260:115:0: - Download-Pfad soll mit
/site-ffms/beginnen und aufsysupgrade.binenden - Der Client / Browser soll
Wgetsein.
Ich habe die dann nach unique-IPv6 Adressen sortiert und jeweils den (zeitlich) jüngsten Eintrag genommen (gibt sonst manchmal dopplungen, wenn der Download der FW nicht auf Anhieb nicht geklappt hat). Da die /site-ffms/... Verzeichnisstruktur nur für im Webserver Konfigurierte Knoten aufrufbar war, kann man manuelle Downloads nahezu komplett ausschließen.
Herausgekommen ist folgende Grafik, in der man schön den Long-Tail-Effekt sehen kann:
Hier die Roh-Daten
+-------+------------+
| COUNT | DATE |
+-------+------------+
| | |
| 42 | 2016-01-08 |
| | |
| 10 | 2016-01-09 |
| | |
| 3 | 2016-01-10 |
| | |
| 38 | 2016-01-11 |
| | |
| 14 | 2016-01-12 |
| | |
| 12 | 2016-01-14 |
| | |
| 192 | 2016-01-15 |
| | |
| 68 | 2016-01-16 |
| | |
| 60 | 2016-01-17 |
| | |
| 9 | 2016-01-18 |
| | |
| 144 | 2016-01-19 |
| | |
| 194 | 2016-01-20 |
| | |
| 40 | 2016-01-21 |
| | |
| 28 | 2016-01-22 |
| | |
| 21 | 2016-01-23 |
| | |
| 37 | 2016-01-24 |
| | |
| 27 | 2016-01-25 |
| | |
| 19 | 2016-01-26 |
| | |
| 7 | 2016-01-28 |
| | |
| 8 | 2016-01-29 |
| | |
| 3 | 2016-01-30 |
| | |
| 12 | 2016-01-31 |
| | |
| 15 | 2016-02-01 |
| | |
| 7 | 2016-02-02 |
| | |
| 14 | 2016-02-03 |
| | |
| 6 | 2016-02-04 |
| | |
| 2 | 2016-02-05 |
| | |
| 5 | 2016-02-06 |
| | |
| 4 | 2016-02-07 |
| | |
| 3 | 2016-02-08 |
| | |
| 1 | 2016-02-09 |
| | |
| 6 | 2016-02-10 |
| | |
| 1 | 2016-02-11 |
| | |
| 8 | 2016-02-12 |
| | |
| 3 | 2016-02-13 |
| | |
| 3 | 2016-02-14 |
| | |
| 2 | 2016-02-15 |
| | |
| 4 | 2016-02-16 |
| | |
| 2 | 2016-02-17 |
| | |
| 2 | 2016-02-18 |
| | |
| 2 | 2016-02-19 |
| | |
| 1 | 2016-02-20 |
| | |
| | |
| | |
| 1079 | Summe |
+-------+------------+
Ich finde das Ergebnis durchaus spannend, da ja vor Beginn der Knotenmigration die Annahme war, dass die eigentliche Migration eine Sache von Stunden oder Tagen ist. Mögliche Ursachen warum das nicht so ist:
- Manche Knoten sprechen (warum auch immer) wohl erst wieder mit dem FW-Server nachdem sie einmal neu gestartet wurden/sind.
- Manche Knoten waren einfach längere Zeit offline.
- Es gibt leider immer noch Leute, die neue Knoten in die Legacy-Domäne bringen.
- …
1 „Gefällt mir“