Admin und Multihost - einige kleinere Bugs

[bb61]

Systemdata	Bitte Ausfüllen
Hardwaresystem:	Pi3,Pi4
Arbeitsspeicher:	1GB,4GB,8GB
Festplattenart:	NAS/SSD im share, HOSTmaster: +lokal SSD
Betriebssystem:	PiOS
Nodejs-Version:	12.(19,20,21).x
NPM-Version:	6.14.(8,10,11)
Installationsart:	Skript

Hi,
folgendes wollte ich nur mal fix melden, damit es bekannt wird und ggf. beachtet werden kann bei künftigen Updates. Alles nichts kriegsentscheidendes, aber letztlich doch lästig bis nahe grenzwertig, mindestens aber wichtig für die sicher mal beabsichtigte Funktion.

Umgebung:
Raspi-Cluster im Multihost, da mehrere Standorte (eigener + Pflegewohnung der Eltern, verbunden im Fritzbox-VPN) bzw. als PROD- bzw. DEV-Geräte bzw. natürlich wg. Aufgaben- u. Lastverteilung auf die kleinen Slaves doch im Laufe der Zeit einige zusammengekommen: Pi3, Pi3B, Pi4(4GB), Pi4(8GB), letztere als JS und neuerdings auch als HOST-Master

Instanzen und Admin sind im aktuellen Patch-Level.

Issues:
(1)
Nimmt man dem HOST-Master (sauber lt. Anleitung) seinen letzten Slave, hat aber zuvor zuletzt im Admin die Log-Ansicht auf einem der ehemaligen Slaves gestellt gehabt (und inzw. längst wieder geschlossen), kann man nie wieder auf die Log-Ansicht des jetzt als Single agierenden Hosts umschalten! Keine Umschalt-Alternative im Kopf mehr vorhanden! (klar, gibt ja nur noch EINEN, eben den exHost, aber Auswahl steht noch auf Slave). Reboot o.ä. hilft auch nicht (jedenfalls nix gefunden).

Einzige Lösung als Workaround: Wieder einen Slave (unter dem ausgegraut immer noch sichtbaren alten Slave-Name im Log-Tab) zuordnen (unter Verlust dessen inzw. neuer Installation/Konfiguration am neuen HOST-Master), dann im Admin das Log zurückstellen auf den Host, alles wieder abmelden und Slave wieder zurück an den neuen Host-Master und da neu konfigurieren etc.

Das geht sicher besser ohne diesen lästigen Weg. Oben im Admin wird in der Umschaltung ja sowieso schon erkannt, dass der Slave nicht da ist (ausgegraut), also könnte dann ja auch der nächste (idealerweise so mehrere existieren: der Host-Master) zumindest hergenommen werden, um überhaupt eine Umschaltalternative / dort eben diesen wieder anzubieten, auch wenn in Summe nur ein Gerät (Host/Slave) im System aktiv ist?

Das wäre sicher bedeutend schneller und auch "normaler / erwartbarer / intuitiver".

(2)
Besagte Umschalt-Box mit den Host-/Slave-Namen, oben in Tabs wie Log, Instanzen, Adapter, aber auch im PopUp bei Installation einer Instanz: SORTIERUNG!

Wie gesagt: Nicht kriegsentscheidend, aber einfach mit der Zeit lästig, besonders wenn die Anzahl der Slaves über die Fensterlänge der Auswahl hinauswächst! (bei mir im Moment 8). Systematische Aufgaben (z.B. Nachsehen ob Updates für die Slaves anstehen, oder Anpassungen von Shares auf allen IO-Engines... usw.) wo war ich schon, wer fehlt noch.... - ewig kommt man durcheinander, besonders wenn man "Silver-Admin", also jenseits des Ereignishorizonts von 50 Jahren angekommen ist!

Früher war es mal konform zur erstmals getätigten Reihenfolge der Slave-Zuordnungen zum Host. Nicht ideal weil, auch da schon nicht wieder änderbar, aber bei Neuzuordnung so erwartbar und einmalig konfigurierbar. - Heute: Absolut willkürliche Reihenfolge (weder alphanumerisch noch in Reihenfolge der ersten Zuweisung der Slaves), die dann aber anschließend merkwürdigerweise konstant bleibt. Woran sich das orientiert ist oder gar einstellbar wäre ist nicht erkennbar!

Gibt es da schon irgend eine Möglichkeit, die Slave-Reihenfolge zu definieren? Wunsch: Default alphanumerisch, aber gerne auch höher-prio determiniert per JSON-Attribut, z.B. als unsignet Int.-Wert aufsteigend im raw-Datensatz der host-Objekte o.ä. Dann könnte man (so man möchte) sogar Slaves gruppieren, also alle IO- oder JS-engines unabhängig vom Namen hintereinander, oder abzulösende Slaves ans Ende schieben usw. Fehlt das attribut oder ist es gleich, wird alphanumerisch sortiert.

Wie übersichtlich es aussehen könnte, kann man in der "Übersicht"-Ansicht sehen. Unter "Hosts" dagegen das gleiche Chaos! Da nützen die so schön einstellbaren Farben und hochladbaren Icons auch nicht viel!

(3)
m.E. ein echter kleiner Rechen-Bug. Thema: Berechnung der freien RAM-Kapazität im Kopf im Tab "Instanzen" fehlerhaft

Offenbar steuert dort die Kapazität des Host-Masters (bei mir ein Raspi4 8GB) den 100%-Wert. Oder wie kommt es nach Umschaltung auf einen Slave (Raspi3, also knapp 1GB RAM) zu der Aussage "Frei: 7% = 567 MB" inkl. Warnfarbe am Wert? 576 von 926 sind nur 7% ??!

Sicher schnell behebbar, und für "wissende" auch unwichtig weil "bekannter Bug" und Info einschätzbar. Aber wenn es schon da steht, sollte es auch stimmen. - Und falls "Warnfarbe" (bzw. %-Wert) irgendwo intern mal künftig "needs Maintenance-"/"bad system health"-Warnungen triggern sollte (was ja nicht doof wäre), wäre es ein defekter Basiswert!

Hinweis: Hat man nur gleich gut mit RAM ausgestattete engines (oder ist auf einer mit Kapazität = die des Host-Masters) ist alles i.O.!

---

Das alles nur als "Jammern auf hohem Niveau", also nur genannt, damit es nicht verloren geht und ein gutes System noch perfekter wird

Gruß von der stürmische Küste
bb61

[UncleSam]

@bb61 Bitte erfasse doch Issues für die einzelnen Probleme in GitHub. Um einen solch riesigen "das geht alles nicht"-Post wird sich kein Entwickler kümmern. Was Multihost betrifft, gehört in js-controller; was Admin betrifft, natürlich in Admin.

Und sorry, ich habe nicht alles gelesen, war mir viel zu lang - aber trotzdem ein Feedback:

@bb61 sagte in Admin und Multihost - einige kleinere Bugs:

Raspi-Cluster im Multihost, da mehrere Standorte (eigener + Pflegewohnung der Eltern, verbunden im Fritzbox-VPN)

Multihost wird grundsätzlich nicht empfohlen wenn mehrere Standorte betroffen sind. Einerseits sind es viele Daten, die übertragen werden und andererseits (und das ist noch viel wichtiger) funktioniert auf dem Slave gar nichts, wenn die Verbindung unterbrochen ist. Verbinde mehrere Standorte zB per MQTT oder Link Adapter.