Node identification behind tunnel is not possible

[estevopaz]

If the server is behind an SSH tunnel, it's impossible to determine what node rendered the job:

"creator":"::ffff:127.0.0.1",
"updatedAt":"2023-05-16T14:00:56.321Z",
"createdAt":"2023-05-16T13:56:11.007Z",
"executor":"::ffff:127.0.0.1",
"startedAt":"2023-05-16T13:56:12.652Z",
"renderProgress":97,
"error":null,
"finishedAt":"2023-05-16T14:00:57.220Z",
"errorAt":null,
"jobCreator":"::ffff:127.0.0.1",
"jobExecutor":"::ffff:127.0.0.1"

This is very problematic when the cluster raises the number of nodes.
Would be possible just to send a custom identification from the client?
Just something like: nexrender-client --node-id "%IP%"
And store nodeId in the JSON?

[inlife]

Hey @estevopaz

I like that you suggested the node-id parameter. We could extend this idea even further, outside of the scope of just IP addresses and a set of manual custom identifiers.

Ideally, if we would wish to identify our worker, we would set up an "--id" or a "--name" even (and I would actually go for the latter). And then that name would show up at the job definition on the server. It would also make sense to generate a name for cases, when it was not set and print it out in the console when the worker starts.
One question I do not have an answer to, is whether the name should be persisted after it was once generated, and if so, how to treat cases with multiple workers per single machine and their name persistence.

The IP should also be present and used, but most likely, we need to combine the name and IP into a single object on the server side. And, if possible, to get rid of duplicated keys "creator", "jobCreator", etc.

How do you think, would a structure like this work?

"updatedAt":"2023-05-16T14:00:56.321Z",
"createdAt":"2023-05-16T13:56:11.007Z",

"creator": {"name":"worker1", "host": "::ffff:127.0.0.1"},
"executor": {"name":"worker1", "host": "::ffff:127.0.0.1"},

"startedAt":"2023-05-16T13:56:12.652Z",
"finishedAt":"2023-05-16T14:00:57.220Z",

"renderProgress":97,
"error":null,
"errorAt":null,

Folks, @Thiago-Dantas @mohali-id, it would also be interesting to get your input on this since you both worked on this feature!

Thanks 🎉

[estevopaz]

That would be a perfect solution, thanks.
About the persistence, IMHO it hasn't a good balance work-profit, but just my opinion.

Thanks Vladyslav.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[estevopaz]

:'(

[inlife]

stale bot does not know what he is doing! it's planned :)

[estevopaz]

Thank you very much ;)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[inlife]

@estevopaz workers now have --name argument which can be used to give a unique (or not) name to a worker

[estevopaz]

Thank you very much, this is very useful for us.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.