Hi all, We made decisions on a few terms at the yesterday's governance meeting:
- Master node => "Built-in Node" - "master" label => "built-in" // We will use it unless we discover a technical issue with the hyphen. Then we fallback to “builtin” - “Master branch” in documentation and help => "default branch" - Agent-to-Master security => " Agent-to-Controller security " - "Jenkins master container " => "Jenkins controller container" - "Serialization whitelist" for JEP-200 => "serialization allowlist" We also agreed that we will be using "allowlist" in our terminology, not the "permitlist" as it was suggested in a few occasions. We have not finalized decisions on other terms, including the "Jenkins master pod". I raised https://github.com/jenkinsci/kubernetes-operator/issues/561 in the Jenkins operator project to track the change on its side once we agree on the term. If anyone is interested, I can create a global "terminology cleanup" project in the jenkinsci organization. It will allow tracking pull request better on the GitHub's side Best regards, Oleg Nenashev On Wednesday, May 5, 2021 at 12:02:42 PM UTC+2 Daniel Beck wrote: > > > > On 4. May 2021, at 16:59, Oleg Nenashev <o.v.ne...@gmail.com> wrote: > > > > • 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.[1] > > 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.) > > > 1: https://github.com/jenkinsci/jenkins/pull/5425 > > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/8507bd02-fbad-4844-aeb9-b1ee58753326n%40googlegroups.com.
