Ja, bitte.
Ich bin gerade dabei das Migrations-Graphen-Nodes-Migrations-Graphen-Selektions-Hierarchie-Whatever-Script zu verfeinern.
Dazu folgende Fragestellung:
@Parad0x sprach mich letztens darauf an, dass es sinnvoll wäre nicht nur den derzeitigen Zustand zu berücksichtigen, sondern auch vergangenes mit einzubeziehen. D. h. in die Berechnung der Migrations-Reihenfolge sollen auch Router mit einbezogen werden, die gerade nicht online sind. Und auch Mesh-Links zu berücksichtigen, die gerade nicht vorhanden sind. Gründe sind wohl Router, die am Stromkreis der Weihnachtsbeleuchtung o. Ä. hängen und daher nicht immer online sind.
Prinzipiell eine gute Überlegung, jedoch sollten wir klären, wie lang der Offline-Zustand vorhanden sein darf, bzw. wie lange der Mesh-Link abgebrochen sein darf, damit er noch in der Berechnung berücksichtigt wird.
Quasi unabhängig davon sollten wir uns außerdem überlegen, wie lange die einzelnen „Wellen“ dauern dürfen. Also wie lange ein Nodes Zeit bekommen sollte sich die aktuelle Firmware abzuholen. Da die Nodes, die schon die neue Firmware haben so lange offline sind, bis alle Nodes auf dem Pfad bis zum Node mit VPN die neue Firmware haben, sollte dieses Intervall auch nicht all zu lang sein.
Um dieses Problem zu umgehen könnte man natürlich alle Mesh-Wolken einzeln betrachten. Das würde jedoch im Vergleich zum Wellen-Verfahren die dynamische Generierung der Webserver-Konfiguration erfordern oder sehr, sehr, sehr viel Handarbeit. Daher und weil die Struktur dahinter einfacher/robuster ist, favorisiere ich das Wellen-Prinzip.