NEWS
Multihost
-
Hallo,
bei mir laufen 4 Raspi's im Multihost. Alles sehr schön stabil - dennoch gibt es ein paar unschöne Effekte :|
(js-controller 1.2.3 - admin 3.1.12; wobei die folgenden Punkte auch schon bei älteren Versionen zu beobachten waren)
- Läuft eine Instanz auf z.B. dem Host 2 und man aktualisiert das Adapter auf dem Host 1, wird auch die Instanz auf dem Host 2 gestoppt. Schön wäre es, wenn nur das Adapter auf dem ausgewähltem Host gestoppt wird.
-> https://github.com/ioBroker/ioBroker.js … issues/181
- Hat man z.B. im Admin den Host 3 ausgewählt und löscht ein Adapter ohne Instanz, dann wird leider das Adapter auf dem Host gelöscht wo eine Instanz läuft. Beim ersten mal sehr ärgerlich - danach macht man es einfach nicht mehr.
-> https://github.com/ioBroker/ioBroker.js … issues/182
- Wählt man im Admin bei "Adapter" den Filter "Adapter mit existing instances", dann werden auch Adapter ohne Instanzen angezeigt; bzw. auch Adapter mit Instanzen auf anderen Hosts.
-> https://github.com/ioBroker/ioBroker.admin/issues/192
- Wechsel des anzuzeigenen Hosts unter iOS nahezu unmöglich; die DropDown Liste kommt zwar - aber die Auswahl eines anderen Hosts funktioniert in > 95% der Fälle nicht.
-> https://github.com/ioBroker/ioBroker.admin/issues/220
- Wechselt man im Admin den Host wird automatisch auf "Adapter" gewechselt; aber dieser wird nicht automatisch aktualisiert (oder die Filter werden nicht berücksichtigt) - gleiches gilt für "Instanzen". Erst nach manueller Aktualisierung wird der RAM Verbrauch, etc. des ausgewählten Hosts angezeigt. Anzeige "RAM usage" ,etc. fände ich sowieso besser unter "Hosts" aufgehoben, damit man mit einem Blick sieht, was bei allen Hosts los ist.
-> hierzu werde/muss ich wohl erstmal den Admin aktualisieren
Schaut mal, ob ihr da nicht das eine oder andere verbessern könnt :P
Danke!
Georg
-
Hast du definitiv ALLE Hosts auf 1.2.3?
Bitte erst einmal ALLES auf js-controller 1.3.0 updaten.
bei Misch-versionen gab es bei Multihost Probleme (1.27. und 1.3.0klappten definitiv nicht zusammen.
Warum hast du noch admin 3.1.2?
Läuft eine Instanz auf z.B. dem Host 2 und man aktualisiert das Adapter auf dem Host 1, wird auch die Instanz auf dem Host 2 gestoppt. Schön wäre es, wenn nur das Adapter auf dem ausgewähltem Host gestoppt wird. `
Das geht nicht, weil die zugrunde legenden Dateien des Adapters geändert werden und dann zu den Instanzen upgeloaded werden.ALLE Adapter-Daten liegen für alle Hosts auf dem Master.
Hat man z.B. im Admin den Host 3 ausgewählt und löscht ein Adapter ohne Instanz, dann wird leider das Adapter auf dem Host gelöscht wo eine Instanz läuft. Beim ersten mal sehr ärgerlich - danach macht man es einfach nicht mehr. `
Dito!Deshalb sollen bei einer Installation eines Slaves darauf auch nur der controller und der Admin sein. Alles andere wird über den Master gemacht.
Wechsel des anzuzeigenen Hosts unter iOS nahezu unmöglich; die DropDown Liste kommt zwar - aber die Auswahl eines anderen Hosts funktioniert in > 95% der Fälle nicht. `
kann an Apfelware liegen, aber auch daran, wenn die Installation nicht sauber durchgeführt wurde.Anzeige "RAM usage" ,etc. fände ich sowieso besser unter "Hosts" aufgehoben, `
Nach der Logik müsste alles unter Hosts liegen ;-)Schaut mal, ob ihr da nicht das eine oder andere verbessern könnt `
Bisher habe ich noch nichts zwingendes entdeckt.Gruß
Rainer
-
Hallo Rainer,
hier ein paar Antworten
> Hast du definitiv ALLE Hosts auf 1.2.3?
Ja, sind alle auf 1.2.3 - 1.3.0 wird noch nicht offiziell angeboten (available = 1.2.3); dann mach ich in der Regel auch kein update.Zu dem Admin 3.1.2 bin ich auch nur durch eine Neuinstallation gekommen - ansonsten wäre ich noch auf dem 2.0.9, weil das die letzte Version ist, die unter "Adapter" als "Available" angezeigt wird.
` > Das geht nicht, weil die zugrunde legenden Dateien des Adapters geändert werden und dann zu den Instanzen upgeloaded werden.
ALLE Adapter-Daten liegen für alle Hosts auf dem Master. `
Versteh ich nicht - macht nix. Bei mir laufen Adapter ggf. auch mit unterschiedlichen Versionen auf den verschiedenen Hosts. Warum sollte man also eine Instanz auf dem Host 2 stoppen nur weil eine Instanz auf dem Host 1 aktualisiert wird? Dann müsste/könnte man auch direkt den Schritt gehen und alle Instanzen eines Adapters auf allen Hosts aktualisieren. Im Moment muss man das leider für jeden Host einzeln machen.> Deshalb sollen bei einer Installation eines Slaves darauf auch nur der controller und der Admin sein. Alles andere wird über den Master gemacht.
Auf dem Slaves soll ein Admin laufen? Ich kann mich erinnern, dass mir jemand (evtl. Du 8-) ) hier geschrieben hat, ich soll auf den Slaves auf keinen Fall einen Admin installieren. Darauf gehört der js-controller, custom setup und der Rest macht der Master, auf den ein Admin gehört.> kann an Apfelware liegen, aber auch daran, wenn die Installation nicht sauber durchgeführt wurde.
Unter Windows/Firefox alles OK - also kein Problem mit der Installation.> Nach der Logik müsste alles unter Hosts liegen
Nö, nur die kleine Zeile mit den Infos unter Instanzen wäre hilfreich - vor allem, weil man ja auch unter iOS fast nicht den Host wechseln kann> Bisher habe ich noch nichts zwingendes entdeckt.
Ich sehe nicht, dass eines der Probleme gelöst ist oder nicht existent ist. Das man den Host unter iOS nicht wechseln kann ist nervig; der Rest "schöner wohnen".Danke!
Georg
-
Versteh ich nicht - macht nix. `
Macht sehr viel, weil davon alles abhängt!Z.b. wären dann deine nächsten Sätze überflüssig.
Erklärbärmodus:
Es gibt eine Grundinstallation, der Konsolenbefehl wäre iobroker install AdapterName.
Dieser Befehl lädt die notwendigen Daten für einen Adapter in ein entsprechendes Verzeichnis, mehr nicht.
Wird nun eine Instanz angelegt, werden dafür diese Installationsdateien verwendet.
Bei einem Upgrade eines Adapters werden erstmal nur die Installationsdateien auf den neuesten Stand gebracht. Anschließend müssen aber noch die laufenden Instanzen upgedated werfen, dies passiert mit upload. Dazu muss die Instanz gestoppt werden.
Instanzen können nicht einzeln aktualisiert werden.
Auf dem Slaves soll ein Admin laufen? `
Ja,vor der Umwandlung in einen slave. Danach läuft er immer noch im Hintergrund, darf aber nicht mehr übers web direkt erreichbar sein.
Gruß Rainer
-
- Wechsel des anzuzeigenen Hosts unter iOS nahezu unmöglich; die DropDown Liste kommt zwar - aber die Auswahl eines anderen Hosts funktioniert in > 95% der Fälle nicht. `
Das kann ich bestätigen und werde noch ein Issue auf Github dazu öffnen.
Bei mir fehlt auch das „Filter“ Feld.
IOS mit Chrome Browser
-
-
Läuft eine Instanz auf z.B. dem Host 2 und man aktualisiert das Adapter auf dem Host 1, wird auch die Instanz auf dem Host 2 gestoppt. Schön wäre es, wenn nur das Adapter auf dem ausgewähltem Host gestoppt wird.
-
Hat man z.B. im Admin den Host 3 ausgewählt und löscht ein Adapter ohne Instanz, dann wird leider das Adapter auf dem Host gelöscht wo eine Instanz läuft. Beim ersten mal sehr ärgerlich - danach macht man es einfach nicht mehr. `
Ja beides bekannt und stört mich auch. GitHub Issues wären denke eine gute Idee …
-
Wählt man im Admin bei "Adapter" den Filter "Adapter mit existing instances", dann werden auch Adapter ohne Instanzen angezeigt; bzw. auch Adapter mit Instanzen auf anderen Hosts.
-
Wechsel des anzuzeigenen Hosts unter iOS nahezu unmöglich; die DropDown Liste kommt zwar - aber die Auswahl eines anderen Hosts funktioniert in > 95% der Fälle nicht.
-
Wechselt man im Admin den Host wird automatisch auf "Adapter" gewechselt; aber dieser wird nicht automatisch aktualisiert (oder die Filter werden nicht berücksichtigt) - gleiches gilt für "Instanzen". Erst nach manueller Aktualisierung wird der RAM Verbrauch, etc. des ausgewählten Hosts angezeigt. Anzeige "RAM usage" ,etc. fände ich sowieso besser unter "Hosts" aufgehoben, damit man mit einem Blick sieht, was bei allen Hosts los ist. `
Hier wäre ich zu allererst bei einem Admin3-Update auf das aktuellste. Wenn immer noch kaputt: GitHub Issues anlegen!!
-
-
Versteh ich nicht - macht nix. `
Macht sehr viel, weil davon alles abhängt!Z.b. wären dann deine nächsten Sätze überflüssig.
Erklärbärmodus:
Es gibt eine Grundinstallation, der Konsolenbefehl wäre iobroker install AdapterName.
Dieser Befehl lädt die notwendigen Daten für einen Adapter in ein entsprechendes Verzeichnis, mehr nicht.
Wird nun eine Instanz angelegt, werden dafür diese Installationsdateien verwendet.
Bei einem Upgrade eines Adapters werden erstmal nur die Installationsdateien auf den neuesten Stand gebracht. Anschließend müssen aber noch die laufenden Instanzen upgedated werfen, dies passiert mit upload. Dazu muss die Instanz gestoppt werden.
Instanzen können nicht einzeln aktualisiert werden. `
Ja aber ich gebe Ihm recht: ioBroker könnte so intelligent sein nur die Instanzen auf dem einen Host neu zu starten wo gerade das Update installiert wurde. Aber es werden alle gestartet. Ist nervig teilweise.
Auf dem Slaves soll ein Admin laufen? `
Ja,vor der Umwandlung in einen slave. Danach läuft er immer noch im Hintergrund, darf aber nicht mehr übers web direkt erreichbar sein. `
Ich würde es anders formulieren: Laufen tut er nicht - also es wird kein Admin prozess gestartet auf einem Slave - es sei denn eine Admin Instanz wurde dort hin verschoben. Dann ist es aber eine "generelle Admin" für alles. Lokale Admins laufen nicht mehr.Die Admin-Adapter-Files liegen aber IMMER auf jedem Slave (weil Admin zusammen mit js-controller installiert wird … IMMER) und von daher werden Updates pot. angeboten :-)
-
` > Erklärbärmodus:
Es gibt eine Grundinstallation, der Konsolenbefehl wäre iobroker install AdapterName.
Dieser Befehl lädt die notwendigen Daten für einen Adapter in ein entsprechendes Verzeichnis, mehr nicht.
Wird nun eine Instanz angelegt, werden dafür diese Installationsdateien verwendet.
Bei einem Upgrade eines Adapters werden erstmal nur die Installationsdateien auf den neuesten Stand gebracht. Anschließend müssen aber noch die laufenden Instanzen upgedated werfen, dies passiert mit upload. Dazu muss die Instanz gestoppt werden.
Instanzen können nicht einzeln aktualisiert werden. `
Das ist mir schon klar. Verstehen will ich aber dennoch nicht, warum man die Instanzen eines Adapters auf einem anderen Host - der ja nicht aktualisert wird - stoppen muss.
-
Moin,
Verstehen will ich aber dennoch nicht, warum man die Instanzen eines Adapters auf einem anderen Host - der ja nicht aktualisert wird - stoppen muss. `
dann versuche ich es mal.-
Wenn ein Adapter aktualisiert wird (über den Admin), werden die Quell-Installationsdaten lokal auf dem Master abgelegt.
-
Damit ist noch kein Update an sich erfolgt, die neuen Files liegen erst mal nur im lokalen „Cache“ (sep. Verzeichnis auf dem Master)
-
Dann werden alle Instanzen dieses Adapters, egal wo sie liegen, gestoppt. Schließlich sind deren „Arbeits-Programmfiles“ andere (älter, oder beim Downgrade auch neuer), als auf dem Master
-
Jetzt werden die Programmfiles vom Master in die Arbeitsverzeichnisse der gestoppten Instanzen kopiert (damit sie mit dem Master übereinstimmen)
-
Danach werden dann die Instanzen wieder gestartet.
Es werden also erst die Adapter-Files in den Quellpfad auf dem Master abgelegt, quasi dort gecached. Und dann werden alle Instanzen damit abgeglichen, um keinen Schiefstand zwischen den Instanzen zu bekommen.
Gruß,
Eric
Von unterwegs getippert
-
-
Sorry Eric aber da muss ich Dir wiedersprechen :)
Die lokalen Adapter-Files liegen immer je Host getrennt. Also Update des Adapters auf dem master updatetet nicht die Slaves mit. Dort musst Du manuell updaten.
Die "Immer alles restarten" liegt daran das ioBroker hier leider, wie oben schon gesagt, nicht sonderlich intelligent arbeitet und vom Standardfall "Singehost" ausgeht. In der Konfig eines Adapters steht ob er oder andere bei einem Update neu gestartet werden sollen und das macht ioBroker halt - für alle Instanzen egal wo diese liegen.Laut http://download.iobroker.net/stat.html haben wir aktuell "237 of 13908" Installationen mit Multihost …
Von daher: Github Issue anlegen dann kann man das man ändern
-
Sorry Eric aber da muss ich Dir wiedersprechen :)
Die lokalen Adapter-Files liegen immer je Host getrennt. Also Update des Adapters auf dem master updatetet nicht die Slaves mit. Dort musst Du manuell updaten.
Die "Immer alles restarten" liegt daran das ioBroker hier leider, wie oben schon gesagt, nicht sonderlich intelligent arbeitet und vom Standardfall "Singehost" ausgeht. In der Konfig eines Adapters steht ob er oder andere bei einem Update neu gestartet werden sollen und das macht ioBroker halt - für alle Instanzen egal wo diese liegen.Laut http://download.iobroker.net/stat.html haben wir aktuell "237 of 13908" Installationen mit Multihost …
Von daher: Github Issue anlegen dann kann man das man ändern `
genau so ist es .. ich habe auf dem slave einen admin und auf dem host auch einen … sollte der eine nicht laufen kann ich über den anderen noch rein..
und.. du musst zuerst den einen updaten dann den anderen .. gestoppt werden aber alle beide wenn du ein update durchführst..
-
Sorry Eric aber da muss ich Dir wiedersprechen :) `
Oh, ok. Das hatte mir mal jemand anders erklärt.Wieder was gelernt.
Gruß,
Eric
Von unterwegs getippert
-
Von daher: Github Issue anlegen dann kann man das man ändern `
Soll das issue für den Admin aufgemacht werden oder JS-Controller ?
-
-
Ich habe noch https://github.com/ioBroker/ioBroker.js … issues/182 dazugeschoben
-
Ich habe noch https://github.com/ioBroker/ioBroker.js … issues/182 dazugeschoben `
Sehr wichtiger Punkt!
Ist mir gerade bei Konfigurations Aufwendigen Adaptern (Modbus Register) schonmal leidlich passiert.
-
-
Kann mir noch kurz jemand erklären, warum es auf GitHub schon die Admin - Version 3.3.5 gibt, in meinem Admin aber als letzte "Available" Version die 2.0.9 angezeigt wird?
1643_unbenannt.png
Support us
629
Online32.6k
Benutzer82.0k
Themen1.3m
Beiträge