NodeIds are random UUIDs, in cluster mode
Description
Environment
Potential Workaround
blocks
Checklist
hideTestRail: Results
Activity
Adam DickmeissFebruary 23, 2017 at 2:11 PM
okapi-259 merged.
Adam DickmeissFebruary 23, 2017 at 9:18 AM
I think we need to step back a little @Wayne Schneider. In short, I'm not sure we'll beniifit of using the URL as an ALTERNATIVE to the real nodeId to refer to to a node.
In Okapi 0.3 we had a system where deployment would only take place at a deployment node. A deployment node does not need database access.. It only needs to access to Hazelcast (memory map). So you'd essentially just deploy at the URL you'd prefer.. You choose the host and port when you launch an Okapi node in deployment mode. It is important to understand that a deployment node only needs to be accessible from proxy nodes.. (not your HAproxy on the outside).
The proxy node however is different.. It is responsible for keeping track of all deployment nodes and routes traffic to them. Proxy nodes are meant to be accessible from the outside or HAproxy or similar.
The mode 'cluster" is a mode where an Okapi node supports BOTH proxy and deployment at the same time.
When the UI team made the console it became apparent that it would be desirable to deploy on arbitrary nodes by using just ONE proxy node because of CORS. For this reason we added a way to deploy modules via a PROXY(&discovery) node. But in order to do that we'd need to specify WHERE to deploy – and that's the nodeId. The UI team got the list of nodes and could just pick and choose where to deploy.. The proxy(and discovery) nodes, thus, was not only proxying but also proxying deployment.
So.. In order to deploy at a node if your choice you don't need to speciify a nodeId .. Just deploy at the node itself (which, clearly involves your knowing the URL of your deployment node).
So instead of
/_/discovery/modulesuse:
/_/deployment/modulesBack to your question about the branch.
"in dev mode, nodeId will be the same as the Okapi host setting. In cluster mode, it will be the Okapi URL"
Not quite:
in dev mode nodeId is the same as host. In cluster mode it is the UUID.
You can use the URL as an alternative to nodeId – in all modes (alternative key).
Question is: do we need the alternative key (URL for nodeId) at all?
Wayne SchneiderFebruary 22, 2017 at 9:59 PM
OK, to clarify: in dev mode, nodeId will be the same as the Okapi host setting. In cluster mode, it will be the Okapi URL. I think we can work with this in our automation scripts - @John Malconian?
Adam DickmeissFebruary 22, 2017 at 9:39 PMEdited
No change in behavior in dev mode. By the way publishing anything that has a nodeId in it is asking for trouble. You can not as a module author know the nodeId of an arbitrary setup!
Wayne SchneiderFebruary 22, 2017 at 3:08 PM
This will change the behavior for an Okapi server running in dev mode, right? So I think that will break most if not all of the deployment descriptors that module authors have published, which mostly look like this:
{
"srvcId" : "inventory",
"nodeId" : "localhost",
"descriptor" : {
"exec" : "java -Dorg.folio.metadata.inventory.storage.type=okapi -Dport=%p -jar ../mod-metadata/inventory/build/libs/inventory.jar"
}
}
Malc emailed this:
Wayne and I came upon an issue deploying modules via Okapi when Okapi is running in 'cluster' mode. Posting the hostname or IP address as the NodeId in the deployment descriptor results in a failed launch of the module with very little information in the okapi log (even when setting log level to 'debug') other than a cryptic 404 status code. Wayne discovered that using the UUID of the Okapi instance as the NodeId, however, results in a successful deployment in 'cluster' mode. This issue is distinct to running in cluster mode. The same limitation does not exist in 'dev' mode.
Is this by design? If so, the use of UUIDs as NodeIds in deployment descriptors does not appear anywhere in the Okapi reference docs to my knowledge.