> On 4. May 2021, at 16:59, Oleg Nenashev <o.v.ne...@gmail.com
> • Master node => "Built-in Node"
To provide a bit of context for this one for those that don't remember from last year :-)
Before, there was no real distinction between "Jenkins master, the process" (mostly) and "Jenkins master, the node". When I worked on the PR in which I started cleaning up the terms, it became apparent a different term could be useful.
A simple example: The built-in node can be offline while the controller is otherwise running.
In some code, the relation between master-specific and global node properties also wasn't clear in some places because both were occasionally called "master" (and only one set is inherited by agents).
There's not a huge list of obvious examples because a lot of the things that could matter are shared (process, file system, config file to an extent) or irrelevant (node launcher).
I still think it would be useful to distinguish in terms between the controller and the built-in node, if only because 'controller' for the node may create wrong associations (it controlling things, rather than "just" being part of the controller process).
However there are also limitations, which make a different term not an obviously correct choice:
- The built-in node is part of the controller process, it shares the controller's file system and OS permissions. If the built-in node is doing work, the controller has load. A lot of resources are shared, so "the built-in node's configuration is stored in the config.xml file with most of the controller configuration on the controller file system" etc.
- People seem to confuse executors and nodes/agents fairly regularly, so may well consider these to be the same thing because the differences are way less relevant than compared to agents, leading to wrong documentation and other advice, possibly confusing those aware of the terms. (It might help that controller as a term is getting rather well established, and that the node will get labels (both UI and environment var) referring to it by its new name, but who knows.)
I encourage you to check out the PR with placeholder term to get a sense for the differences and consider whether you think distinguishing the terms is useful. As the PR is still a draft and uses an obvious placeholder term, please skip doing an actual review for now.
(Note that the behavior-changing code in my PR (related to migration) would be needed anyway, regardless of the term we choose. It's more about removing "master" than what the replacement term is.)