• Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Minor Minor
    • core

      There is an inconsistent mixture of "slave" and "node" throughout the Jenkins core UI.
      For example, viewing the details of a slave shows the title "Slave foo", the breadcrumb "Jenkins > Nodes > foo", and the URL /computer/foo.

      As per JENKINS-27268, all instances of "slave" were renamed to "agent", and the changes were merged into the Jenkins 2.0 branch.

      Ideally we should take this chance to stop using the word "node" — I think it has much less meaning for regular users, and in general, compared to "agent".

      i.e. everywhere where "Node" is at the moment should become "Agent".

          [JENKINS-33007] Rename "node" to "agent" throughout Jenkins

          Tyler reminded me that the Jenkins master is available for build execution, which is perhaps why we have the mixture of references to nodes and slaves.

          But it wouldn't be so bad to call everything "agent" anyway? Master already has an arguably confusing dual purpose: managing configuration and everything, and also being a build executor (in an out-of-the-box Jenkins install). So we could say that the master has an agent embedded within it.

          Christopher Orr added a comment - Tyler reminded me that the Jenkins master is available for build execution, which is perhaps why we have the mixture of references to nodes and slaves. But it wouldn't be so bad to call everything "agent" anyway? Master already has an arguably confusing dual purpose: managing configuration and everything, and also being a build executor (in an out-of-the-box Jenkins install). So we could say that the master has an agent embedded within it.

          Daniel Beck added a comment -

          Related IRC discussion:

          [2016-02-29T22:13:38+0100] <rtyler> orrc: I thought that was going to happen in 2.0 anyways?
          [2016-02-29T22:13:52+0100] <orrc> slave -> agent is done
          [2016-02-29T22:14:00+0100] <rtyler> right
          [2016-02-29T22:14:04+0100] <orrc> so now we have "agent" and "node"
          [2016-02-29T22:14:42+0100] <rtyler> ah right, you and I already talked about this I see
          [2016-02-29T22:14:47+0100] • rtyler: cheers
          [2016-02-29T22:15:16+0100] <orrc> yeah. so because of technical reasons, users get to see a mixture of terms, as I understand it
          [2016-02-29T22:34:10+0100] <batmat> orrc: nodes = any machine in a Jenkins cluster, agent aka slave
          [2016-02-29T22:34:23+0100] <batmat> orrc: was the discussion on the gov meeting for the rename
          [2016-02-29T22:34:31+0100] <batmat> and why node wasn't selected
          [2016-02-29T22:34:39+0100] <orrc> batmat: you misunderstand :)
          [2016-02-29T22:34:58+0100] <orrc> batmat: I'd like to kill the word "node" entirely from Jenkins — node is already used
          [2016-02-29T22:36:11+0100] <batmat> orrc: well, why not merge into one word, I'm not sure, but not sure agent is better to keep than node :)
          [2016-02-29T22:37:20+0100] <rtyler> batmat: did you see orrc's comment on the ticket above from last time we discussed this?
          [2016-02-29T22:38:30+0100] <orrc> batmat: https://i.imgur.com/KCgg1in.png
          [2016-02-29T22:38:43+0100] <orrc> "Slave foo" / "Mark this node offline"
          [2016-02-29T22:39:00+0100] <orrc> also nice: "This *node* is offline because the *slave* agent failed to launch"
          [2016-02-29T22:39:10+0100] • orrc: wonders how "slave agent" got translated in "slave" -> "agent"
          [2016-02-29T22:40:11+0100] <batmat> orrc: yeah right. IMO we should indeed review that screen in the 2.0 alpha (or the branch itself, and `git grep`ing that string)
          [2016-02-29T22:41:01+0100] <orrc> batmat: I'd rather "node" wasn't used anyway — we've chosen "agent" to mean a machine where builds are happening, so it would be nice to use that *everywhere*
          [2016-02-29T22:41:08+0100] <orrc> s/anyway/anywhere
          [2016-02-29T22:46:29+0100] <orrc> with Jenkins 2.0: https://i.imgur.com/rkVktB8.png
          …
          [2016-02-29T22:51:23+0100] <@danielbeck> orrc node includes master, agent does not. That was my understanding. Otherwise we need more terminology
          …
          [2016-02-29T22:54:18+0100] <orrc> danielbeck: yeah, that's clear. technically everything is a node, but there's no reason to expose this terminology to users. if master has executors (as it does by default) that's an agent that can run builds for me. if I attach another agent, that's another agent that can run builds for me
          [2016-02-29T22:54:47+0100] <@danielbeck> IOW it's just redundant and you now have "agents other than master"
          [2016-02-29T22:55:53+0100] <@danielbeck> rtyler I don't think it's possible
          [2016-02-29T22:57:00+0100] <@danielbeck> orrc AFAIK the intention was to have a drop in replacement for 'slave', so having 'agent' mean the same as 'node' would change its meaning and lead to the problem that you have no term for what used to be called slave.
          …
          [2016-02-29T23:01:58+0100] <orrc> danielbeck: what type of problems are you thinking of that would be caused by "node" being called "agent"?
          [2016-02-29T23:02:42+0100] <@danielbeck> You mean besides confusion and redundancy, and the fact that we don't have a new term for what used to be called Slave?
          [2016-02-29T23:04:14+0100] <@danielbeck> Master is a node. A slave is a node. Master is not a slave. So we need to be very clear about which term we're replacing with another one, and that term is 'slave'.
          [2016-02-29T23:04:55+0100] <@danielbeck> Otherwise you'll just have 'agent' mean 'node', and people will continue using 'slave' because there's no alternative, and we won't have accomplished anything.
          [2016-02-29T23:05:04+0100] <abayer> Yeah, that makes sense to me.
          [2016-02-29T23:06:22+0100] <abayer> If we'd architected things such that the executors on the master were also a "slave" rather than within the existing master JVM, then "agent" as all-purpose "box with executors" would make sense, but given the distinction between master executors and non-master executors, keeping separate terminology makes sene.
          [2016-02-29T23:06:23+0100] <abayer> sense
          [2016-02-29T23:06:39+0100] <orrc> I don't see why people would keep using "slave" because the job-executing part of master was renamed to "agent"
          [2016-02-29T23:07:43+0100] <orrc> master does coordination, but also (optionally) runs as an agent for me, executing builds. same as an external agent
          [2016-02-29T23:08:02+0100] <orrc> but yeah, I kinda see what you're saying abayer
          [2016-02-29T23:08:13+0100] <orrc> and there was talk of splitting this up at the 2.0 summit :)
          …
          [2016-02-29T23:08:46+0100] <abayer> I'm thinking about it like Puppet masters and agents - you run the Puppet agent on the Puppet master too, but it's a separate process, etc...
          …
          [2016-02-29T23:09:40+0100] <orrc> abayer: right. but why should end users care about this technical distinction within Jenkins core?
          [2016-02-29T23:11:10+0100] <@danielbeck> orrc Are you offering to write the user and dev docs that explain this mess? Because it's pretty straightforward with node/master/agent. Agent/master/???, not so much.
          [2016-02-29T23:11:38+0100] <rtyler> is anybody at all willing to write any user and dev docs that explain any messes? :(
          [2016-02-29T23:11:47+0100] • rtyler: quietly agents away over jenkins docs
          [2016-02-29T23:12:47+0100] <orrc> danielbeck: my argument that it's not straightforward. and I genuinely don't see why having one thing called "agent", which master can also be, is a mess
          [2016-02-29T23:13:24+0100] <orrc> and yeah, the idea was to then ensure that as much documentation as possible uses the one term. rather than "node", "agent", "slave", "build machine", "worker" and whatever else is out there
          

          Daniel Beck added a comment - Related IRC discussion: [2016-02-29T22:13:38+0100] <rtyler> orrc: I thought that was going to happen in 2.0 anyways? [2016-02-29T22:13:52+0100] <orrc> slave -> agent is done [2016-02-29T22:14:00+0100] <rtyler> right [2016-02-29T22:14:04+0100] <orrc> so now we have "agent" and "node" [2016-02-29T22:14:42+0100] <rtyler> ah right, you and I already talked about this I see [2016-02-29T22:14:47+0100] • rtyler: cheers [2016-02-29T22:15:16+0100] <orrc> yeah. so because of technical reasons, users get to see a mixture of terms, as I understand it [2016-02-29T22:34:10+0100] <batmat> orrc: nodes = any machine in a Jenkins cluster, agent aka slave [2016-02-29T22:34:23+0100] <batmat> orrc: was the discussion on the gov meeting for the rename [2016-02-29T22:34:31+0100] <batmat> and why node wasn't selected [2016-02-29T22:34:39+0100] <orrc> batmat: you misunderstand :) [2016-02-29T22:34:58+0100] <orrc> batmat: I'd like to kill the word "node" entirely from Jenkins — node is already used [2016-02-29T22:36:11+0100] <batmat> orrc: well, why not merge into one word, I'm not sure, but not sure agent is better to keep than node :) [2016-02-29T22:37:20+0100] <rtyler> batmat: did you see orrc's comment on the ticket above from last time we discussed this? [2016-02-29T22:38:30+0100] <orrc> batmat: https://i.imgur.com/KCgg1in.png [2016-02-29T22:38:43+0100] <orrc> "Slave foo" / "Mark this node offline" [2016-02-29T22:39:00+0100] <orrc> also nice: "This *node* is offline because the *slave* agent failed to launch" [2016-02-29T22:39:10+0100] • orrc: wonders how "slave agent" got translated in "slave" -> "agent" [2016-02-29T22:40:11+0100] <batmat> orrc: yeah right. IMO we should indeed review that screen in the 2.0 alpha (or the branch itself, and `git grep`ing that string) [2016-02-29T22:41:01+0100] <orrc> batmat: I'd rather "node" wasn't used anyway — we've chosen "agent" to mean a machine where builds are happening, so it would be nice to use that *everywhere* [2016-02-29T22:41:08+0100] <orrc> s/anyway/anywhere [2016-02-29T22:46:29+0100] <orrc> with Jenkins 2.0: https://i.imgur.com/rkVktB8.png … [2016-02-29T22:51:23+0100] <@danielbeck> orrc node includes master, agent does not. That was my understanding. Otherwise we need more terminology … [2016-02-29T22:54:18+0100] <orrc> danielbeck: yeah, that's clear. technically everything is a node, but there's no reason to expose this terminology to users. if master has executors (as it does by default) that's an agent that can run builds for me. if I attach another agent, that's another agent that can run builds for me [2016-02-29T22:54:47+0100] <@danielbeck> IOW it's just redundant and you now have "agents other than master" [2016-02-29T22:55:53+0100] <@danielbeck> rtyler I don't think it's possible [2016-02-29T22:57:00+0100] <@danielbeck> orrc AFAIK the intention was to have a drop in replacement for 'slave', so having 'agent' mean the same as 'node' would change its meaning and lead to the problem that you have no term for what used to be called slave. … [2016-02-29T23:01:58+0100] <orrc> danielbeck: what type of problems are you thinking of that would be caused by "node" being called "agent"? [2016-02-29T23:02:42+0100] <@danielbeck> You mean besides confusion and redundancy, and the fact that we don't have a new term for what used to be called Slave? [2016-02-29T23:04:14+0100] <@danielbeck> Master is a node. A slave is a node. Master is not a slave. So we need to be very clear about which term we're replacing with another one, and that term is 'slave'. [2016-02-29T23:04:55+0100] <@danielbeck> Otherwise you'll just have 'agent' mean 'node', and people will continue using 'slave' because there's no alternative, and we won't have accomplished anything. [2016-02-29T23:05:04+0100] <abayer> Yeah, that makes sense to me. [2016-02-29T23:06:22+0100] <abayer> If we'd architected things such that the executors on the master were also a "slave" rather than within the existing master JVM, then "agent" as all-purpose "box with executors" would make sense, but given the distinction between master executors and non-master executors, keeping separate terminology makes sene. [2016-02-29T23:06:23+0100] <abayer> sense [2016-02-29T23:06:39+0100] <orrc> I don't see why people would keep using "slave" because the job-executing part of master was renamed to "agent" [2016-02-29T23:07:43+0100] <orrc> master does coordination, but also (optionally) runs as an agent for me, executing builds. same as an external agent [2016-02-29T23:08:02+0100] <orrc> but yeah, I kinda see what you're saying abayer [2016-02-29T23:08:13+0100] <orrc> and there was talk of splitting this up at the 2.0 summit :) … [2016-02-29T23:08:46+0100] <abayer> I'm thinking about it like Puppet masters and agents - you run the Puppet agent on the Puppet master too, but it's a separate process, etc... … [2016-02-29T23:09:40+0100] <orrc> abayer: right. but why should end users care about this technical distinction within Jenkins core? [2016-02-29T23:11:10+0100] <@danielbeck> orrc Are you offering to write the user and dev docs that explain this mess? Because it's pretty straightforward with node/master/agent. Agent/master/???, not so much. [2016-02-29T23:11:38+0100] <rtyler> is anybody at all willing to write any user and dev docs that explain any messes? :( [2016-02-29T23:11:47+0100] • rtyler: quietly agents away over jenkins docs [2016-02-29T23:12:47+0100] <orrc> danielbeck: my argument that it's not straightforward. and I genuinely don't see why having one thing called "agent", which master can also be, is a mess [2016-02-29T23:13:24+0100] <orrc> and yeah, the idea was to then ensure that as much documentation as possible uses the one term. rather than "node", "agent", "slave", "build machine", "worker" and whatever else is out there

          Jesse Glick added a comment -

          I thought this was done already?

          Jesse Glick added a comment - I thought this was done already?

          Daniel Beck added a comment - - edited

          jglick We renamed 'slave' to 'agent', but some, including orrc appear to want to get rid of this nice taxonomy (master is a node, but not an agent) to make 'agent' a second, redundant term for 'node', and remove its meaning of "a node that is not master" (superseding 'slave') that we currently have.

          Daniel Beck added a comment - - edited jglick We renamed ' slave ' to 'agent', but some, including orrc appear to want to get rid of this nice taxonomy (master is a node, but not an agent) to make 'agent' a second, redundant term for 'node', and remove its meaning of "a node that is not master" (superseding 'slave') that we currently have.

          Oleg Nenashev added a comment -

          I agree with orrc that the new "nice" taxonomy is a total mess if we take the huge amount of legacy info about Jenkins where nodes are... a kind of builders (including remote nodes). I would vote for Agent with "On-master agent" and "Remote agent" types.

          Oleg Nenashev added a comment - I agree with orrc that the new "nice" taxonomy is a total mess if we take the huge amount of legacy info about Jenkins where nodes are... a kind of builders (including remote nodes). I would vote for Agent with "On-master agent" and "Remote agent" types.

            Unassigned Unassigned
            orrc Christopher Orr
            Votes:
            1 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated: