Short problem description: Job on dedicated slave not started since Jenkins 2.71

       

      Detailed description:

      1. I have jobs that run only on slave nodes with dedicated labels (label-A && label-B).
      2. Then, I have slave nodes that contain these labels label-A, label-B, label-C, ... .
      3. In the slave node configuration, I have also configured that only a special user (user-ID coming from LDAP) is allowed to run jobs on this slave.
      4. Problem: when I want to launch the job, the job is queued with the hint Node.LabelMissing (I found it in Google: https://github.com/jenkinsci/jenkins/blob/master/core/src/main/resources/hudson/model/Messages_de.properties). When I move the mouse over the job in the queue, I get more details about the missing label. The list contains many many slave nodes which do not contain the label, which is correct. But it seems that my dedicated node is not considered at all.
      5. After rolling back to Jenkins 2.70 (exchanging the war file, no change in plugins), the job can be started without any problems.

          [JENKINS-45959] Node.LabelMissing error in Jenkins 2.71

          Jesse Glick added a comment -

          In the slave node configuration, I have also configured that only a special user (user-ID coming from LDAP) is allowed to run jobs on this slave.

          Could you be more specific about how you have configured this? Some special plugin? Are there steps to reproduce this issue from scratch in a fresh installation (the Mock Agent and Mock Security Realm plugins are convenient for such cases)?

          Looking over changes in 2.71 I do not see anything obviously related to queue maintenance. There were some changes in User lookup which should not have had behavioral effects but it is possible, especially if some plugin is manipulating users in an unusual way.

          Jesse Glick added a comment - In the slave node configuration, I have also configured that only a special user (user-ID coming from LDAP) is allowed to run jobs on this slave. Could you be more specific about how you have configured this? Some special plugin? Are there steps to reproduce this issue from scratch in a fresh installation (the Mock Agent and Mock Security Realm plugins are convenient for such cases)? Looking over changes in 2.71 I do not see anything obviously related to queue maintenance. There were some changes in User lookup which should not have had behavioral effects but it is possible, especially if some plugin is manipulating users in an unusual way.

          Michael M. added a comment -

          The slave node configuration was done like this:

          After changing the user-id to lowercase t12345 it works with Jenkins 2.73 now.

          So the problem was realted to some user-id stuff, thanks for the hint.

          Feel free to close this issue.

          Michael M. added a comment - The slave node configuration was done like this: After changing the user-id to lowercase t12345 it works with Jenkins 2.73 now. So the problem was realted to some user-id stuff, thanks for the hint. Feel free to close this issue.

          Jesse Glick added a comment -

          Seems like a possible core regression affecting job-restrictions. I am not familiar with this code but oleg_nenashev may be able to evaluate. From a quick look I think AbstractUserCauseRestriction is at fault for not taking into account the realm’s configured user & group IdStrategy. Not exactly sure how the 2.71 update would have changed that; perhaps the UserIdCause constructor is behaving differently w.r.t. stored vs. in-memory user IDs?

          Jesse Glick added a comment - Seems like a possible core regression affecting job-restrictions . I am not familiar with this code but oleg_nenashev may be able to evaluate. From a quick look I think AbstractUserCauseRestriction is at fault for not taking into account the realm’s configured user & group IdStrategy . Not exactly sure how the 2.71 update would have changed that; perhaps the UserIdCause constructor is behaving differently w.r.t. stored vs. in-memory user IDs?

          Oleg Nenashev added a comment -

          I need to check it, but it looks bad

          Oleg Nenashev added a comment - I need to check it, but it looks bad

          Ilia Shakitko added a comment -

          jglick was it starting before? I have Jenkins 2.60.3.1 and if I restrict a node with label "restrict" usage to a user id "test", job pipeline with code:

          node('restrict') {
            sleep 10
            echo 'Hello World'
          }
          

          just hangs/stays in build queue (both users "test" and "admin")

          Started by user admin
          [Pipeline] node
          Still waiting to schedule task
          ; Jenkins doesn’t have label restrict
          

          If I uncheck restriction it works obviously.

          Not sure is it the same issue or a separate one? oleg_nenashev

          Ilia Shakitko added a comment - jglick was it starting before? I have Jenkins 2.60.3.1  and if I restrict a node with label "restrict" usage to a user id "test", job pipeline with code: node( 'restrict' ) { sleep 10 echo 'Hello World' } just hangs/stays in build queue (both users "test" and "admin") Started by user admin [Pipeline] node Still waiting to schedule task ; Jenkins doesn’t have label restrict If I uncheck restriction it works obviously. Not sure is it the same issue or a separate one? oleg_nenashev

          Oleg Nenashev added a comment -

          Maybe it's the same one. I will try to take a look after Jenkins World

          Oleg Nenashev added a comment - Maybe it's the same one. I will try to take a look after Jenkins World

          Ilia Shakitko added a comment -

          oleg_nenashev I am also in Jenkins World. Let's connect  We can have a look together.

          Ilia Shakitko added a comment - oleg_nenashev I am also in Jenkins World. Let's connect  We can have a look together.

            Unassigned Unassigned
            michaelmotteler Michael M.
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: