Add Node Owner-Ship

[dh3wr]

Der Übersicht halber wäre eine owner-Eigenschaft bei den Nodes super. Ist das möglich?

[Taronyu]

Ja, das müsste sich eigentlich analog zu den Transmittern realisieren lassen.

[Taronyu]

Das ist nun analog zu den anderen Ownerlisten implementiert.

ACHTUNG: in der State.json muss vor dem Start die Ownerliste eines Knotens befüllt werden, sonst schlägt der Validator fehl und der Core startet nicht mehr.

"nodes": {
  "node_name": {
    "name": "node1",
    "ownerNames": [ "node_owner" ],
    ...
  }
}

Alternativ gibt es nun die Option --enforce-startup, die beim Start über die Kommandozeile an den Core übergeben werden kann (ans Ende anfügen, also nach der jar-Datei). Dadurch werden die State Validation Fehler, die beim initialien Laden der State.json gefunden werden, ignoriert. Wenn der betroffene Core sich dann mit dem Cluster verbindet, bekommt er ja den aktuellen State. So muss man das nur bei einem Core updaten und alle anderen können sich das dann mittels State-Transfer einfach runterladen.

[dh3wr]

ok, ich habe das für das Web-Interface vorgemerkt und werde dann die State.json entsprechend umbauen und die Sysops informieren

[dh3wr]

Die Umstellung ist durch Hinzufügen von -NodeOwner an den Versionsstring möglich gewesen. Allerdings hat PutNode noch ein Problem. Obwohl die RESTAPI richtig besendet wird mit Status "ONLINE", ist der Knoten danach suspended. Core-Ausgabe:

15:55:33.603 [nioEventLoopGroup-3-3] ERROR org.dapnet.core.transmission.ServerHandler - Closing connection: Invalid welcome message format: [UniPager-Dummy v0.5.1  ]
15:55:33.603 [nioEventLoopGroup-3-3] INFO  org.dapnet.core.transmission.ServerHandler - Connection closed.
15:55:34.040 [grizzly-http-server-0] INFO  org.dapnet.core.cluster.ClusterManager - Cluster has Quorum
15:55:34.042 [Incoming-1,DAPNET1.1.3.1-SNAPSHOT-NodeOwner,db0sda] INFO  org.dapnet.core.cluster.ClusterManager - Cluster has Quorum
15:55:34.043 [Incoming-1,DAPNET1.1.3.1-SNAPSHOT-NodeOwner,db0sda] INFO  org.dapnet.core.cluster.ClusterManager - Cluster has Quorum
15:55:34.043 [Incoming-1,DAPNET1.1.3.1-SNAPSHOT-NodeOwner,db0sda] INFO  org.dapnet.core.cluster.RpcListener - PutNode Node{status=SUSPENDED, name='db0sda'}: OK

Wird hier etwas initialisiert, was es nicht sollte?

[Taronyu]

Jo, das wird im Code explizit auf SUSPENDED gesetzt:

if (node != null) {
    node.setName(nodeName);
    node.setStatus(Node.Status.SUSPENDED);
}

Früher konnte ein neu hinzugefügter Knoten gar nicht online sein, da machte das wohl Sinn. Die Authentifizierung läuft aber nun über dieses SimpleToken. Es müsste daher jetzt möglich sein, sich schon vorher zu verbinden, wenn man das Secret kennt. Das dürfte dann eine Art Geist-Knoten werden, der nicht in über die API sichtbar ist (auch irgendwie doof). Wenn der Knoten angelegt wurde, wechselt der Status natürlich auch erst bei einem Reconnect des Knotens (SUSPENDED nach ONLINE).

Was ich an der Stelle implementieren könnte: Wenn ein unbekannter Knoten joint, wird automatisch ein Knoten mit dem aus der Clusterconfig gemeldeten Namen angelegt. So wäre der Knoten zumindest sichtbar. Müsste ich aber noch checken, ob das mit dem Validator funktioniert, es fehlte dann ja der Owner beispielsweise (oder der muss dann halt leer bleiben).

Edit: So das erst mal als Idee, ohne Garantie auf technische Machbarkeit :)

[dh3wr]

OK, die Stelle habe ich gerade auch gefunden :-). Es ging im speziellen Fall hier darum, bei einem Node nur die Koordianten zu ändern. Oder auch owner zu editieren. Dazu muss der Knoten ja nicht neu gestartet werden oder die Cluster-Konnection sich ändern. PUT scheint hier also von einem ganz neuen Knoten auszugehen. Vielleicht brauchen wir eine separate Funktion für die Änderungen von "nicht-Cluster-Relevanten" Meta Daten wie owner oder location?

[dh3wr]

Nach einem PUT hat der Node keine IP und keinen Port mehr.

[Taronyu]

Ist gefixt

[dh3wr]

Geht alles