• Icon: Task Task
    • Resolution: Fixed
    • Icon: Major Major
    • kubernetes-plugin
    • None
    • 4265.v78b_d4a_1c864a_

      When a Jetty 12 Jenkins test harness is used (i.e., one built from the prototype branch of jenkins-test-harness), tests based on these harnesses fail:

      • src/test/java/org/jvnet/hudson/test/JenkinsRuleNonLocalhost.java
      • src/test/java/org/jvnet/hudson/test/RestartableJenkinsNonLocalhostRule.java

      Ideally a change could be found that can be delivered against the current release of Jetty 10 while also being forward compatible with Jetty 12. If not, then the PR will have to remain in draft until we release JTH with Jetty 12 support. Either way, we should prepare the PR in advance.

          [JENKINS-73138] Adapt Kubernetes for Jetty 12 (EE 8)

          Jesse Glick added a comment -

          JenkinsRuleNonLocalhost was not a great idea to begin with. https://github.com/jenkinsci/kubernetes-plugin/pull/1567#pullrequestreview-2090682601 has some related discussion, but briefly: the problem is that K8s agents are inbound (JNLPLauncher, whether TCP or WebSocket) and when the controller runs outside the cluster they would not be able to access it easily because they are not both on localhost, and the host IP is not readily accessible. CI tests do not have quite the same issue because they run mvn test inside the cluster so there is a well-defined host name, but it is still not on loopback. I think this does not matter for the TCP port, but the current hack is to expose the Jenkins HTTP port to all network interfaces, which is not supported in JTH pending https://github.com/jenkinsci/jenkins-test-harness/pull/289#issuecomment-809560892 (since it is so easy to expose yourself to a serious vulnerability unless you take care to ensure that every single test enables security with a strong random password). And so the plugin’s fork of JenkinsRule is awkward to maintain.

          It would be safer and more robust to use ktunnel or some similar system to set up a reverse proxy for both ports that allows agent pods running inside the cluster to contact the controller, without exposing the controller’s HTTP port to outside traffic. Ideally this would also be available for hpi:run but at worst you can just add a Thread.sleep to some test, wait for it to pause, and then experiment interactively.

          Jesse Glick added a comment - JenkinsRuleNonLocalhost was not a great idea to begin with. https://github.com/jenkinsci/kubernetes-plugin/pull/1567#pullrequestreview-2090682601 has some related discussion, but briefly: the problem is that K8s agents are inbound ( JNLPLauncher , whether TCP or WebSocket) and when the controller runs outside the cluster they would not be able to access it easily because they are not both on localhost, and the host IP is not readily accessible. CI tests do not have quite the same issue because they run mvn test inside the cluster so there is a well-defined host name, but it is still not on loopback. I think this does not matter for the TCP port, but the current hack is to expose the Jenkins HTTP port to all network interfaces, which is not supported in JTH pending https://github.com/jenkinsci/jenkins-test-harness/pull/289#issuecomment-809560892 (since it is so easy to expose yourself to a serious vulnerability unless you take care to ensure that every single test enables security with a strong random password). And so the plugin’s fork of JenkinsRule is awkward to maintain. It would be safer and more robust to use ktunnel or some similar system to set up a reverse proxy for both ports that allows agent pods running inside the cluster to contact the controller, without exposing the controller’s HTTP port to outside traffic. Ideally this would also be available for hpi:run but at worst you can just add a Thread.sleep to some test, wait for it to pause, and then experiment interactively.

          Basil Crow added a comment -

          I don't doubt that there are deeper cleanups to be made, but given the tight timeline of this project I am only expecting a mechanical adaptation from Jetty 10 to Jetty 12.

          Basil Crow added a comment - I don't doubt that there are deeper cleanups to be made, but given the tight timeline of this project I am only expecting a mechanical adaptation from Jetty 10 to Jetty 12.

            jglick Jesse Glick
            basil Basil Crow
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: