Skip to content
Browse files
[JENKINS-45841, JENKINS-43985] - Remoting Update, Aug 2017. Protocol …
…deprecation, Java 8 and plans
  • Loading branch information
oleg-nenashev authored and rtyler committed Aug 11, 2017
1 parent 6c85533 commit c5f1e6510c2a8160dfc84ae71d02a991b1de8c76
Showing with 135 additions and 0 deletions.
  1. +135 −0 content/blog/2017/08/2017-08-11-remoting-update.adoc
@@ -0,0 +1,135 @@
layout: post
title: "Remoting Update. Protocols deprecation, Java 8 requirement and plans"
- remoting
- agents
- announcement
- upgrade
- core
author: oleg_nenashev

This is an announcement about incoming changes in the Jenkins core,
which **may** require extra actions during the upgrade.
If you use configuration-as-code or other configuration management for Jenkins agents,
please read this announcement carefully.

If you have ever seen messages like "Channel is already closed" or "Remote call failed" in your build logs,
you have already met link:/projects/remoting[Jenkins Remoting].

Remoting is an agent executable (aka `slave.jar`) and a library implementing the communication layer between Jenkins masters and their agents (including communication protocols, distributed calls and classloading).
It is also used in several other cases: link:[Maven Integration Plugin], Remoting-based CLI, etc.

In order to make it clear what's changing in Jenkins Remoting, I have documented the various components on
link:/projects/remoting[the Remoting's sub-project page], and will try to publish regular updates about the status of
Remoting to this site and the link:/mailing-lists[developer mailing list].

In this blogpost I would like to provide an update on the Remoting roadmap and to announce two major incoming changes: deprecation of old protocols and upgrade to Java 8.
Both changes will take place in one of the next Weekly releases.
ETA is Jenkins 2.75 on Aug 20, 2017.

Below are details on the incoming changes and compatibility notes.

## Old Remoting Protocols Deprecation

It has been almost one year since the release of JNLP4-connect protocol in Remoting 3.0.
This protocol has been enabled by default since 2.46.x, and so far it demonstrates good stability being compared to JNLP2 and JNLP3 protocols.

At the governance meeting
link:[we decided] to disable old Remoting protocols (JNLP/JNLP2 + CLI1) in new installations by default.
There are 3 reasons for it:

1. Maintenance of multiple protocols takes a lot of extra effort.
The JNL2 NIO engine is complex and barely diagnosable.
2. There are known issues in JNLP2 connection management (see link:/projects/remoting/[the protocol's Errata]). In many cases update to JNLP4 was a resolution
3. JNLP1/JNLP2/CLI1 are unencrypted, and it is not something Jenkins users may expect in 2017

It is tracked as link:[JENKINS-45841] in Jenkins JIRA.

### How?

* When Jenkins is started in the new installation mode with enabled Installation Wizard, old protocols will be disabled
* Jenkins shows an administrative warning when obsolete protocols are enabled

### Compatibility notes

Older instances won't be affected by the disabling of the older JNLP1/JNLP2 protocols, which will still be enabled for them.
Newly created instances which skip, or disable, the Setup Wizard will not be affected either.

"New" Jenkins instances installed via setup wizard **may be affected** in edge cases. For example:

* Agents with Remoting older than 3.0 will be unable to connect.
** **Mitigation:** Before updating make sure Remoting is not bundled custom Docker images, AMIs, etc.
* Swarm Plugin: old versions of Swarm Client (before 3.3) will be unable to connect to Jenkins, because Remoting 2.x is bundled
** **Mitigation**: Update Swarm Client
* **Very** old jenkins-cli.jar without CLI2 support will be unable to connect.
** **Mitigation**: Do not use Remoting-based CLI on new instances (see link:/blog/2017/04/11/new-cli/[this blogpost])

## Upgrade to Java 8

Starting with version 2.54, Jenkins requires Java 8 to run
(link:/blog/2017/04/10/jenkins-has-upgraded-to-java-8/[announcement blog post]).
This version is also required for Jenkins LTS 2.60.1.

Remoting continued to support Java 7 for a while for backporting purposes,
but it will be also upgraded to Java 8 in the Remoting 3.11 release.
Thit Rremoting version is expected to be available in Jenkins 2.75 (ETA: Aug 20, 2017).
This change is tracked as link:[JENKINS-43985].

### Compatibility notes

The update does not cause compatibility issues in common use-cases.
However, there may be issues in custom Jenkins core builds and packaging.
There are several examples below.

* Jenkins instances with built-in Remoting versions will **NOT** be affected, Java 8 is already required there
* Users of community-provided Docker packages (link:[docker-slave],
link:[docker-jnlp-slave]) will **NOT** be affected,
Java 8 is already required there
* **Custom** Jenkins WAR file builds targeting Java 7 may fail to build/run if they bundle Remoting 3.11 or later
* **Custom** Jenkins agent instances (manually installed hosts, VM snapshots, Docker packages, AMIs, etc.) may fail if they download the latest Remoting version and use Java 7

### Java 9 support

As with Jenkins core, Java 9 **not supported** and **not tested** in Remoting.
It may work in some configurations, but it is not guaranteed.

As a consequence, it is not recommended to run Remoting with Java 9 right now.
It is also not recommended to use link:[Maven Integration Plugin] to run builds on Java 9.

## What's next?

There are some ongoing activities in the Remoting sub-project:

1. Stability and Diagnosability improvements
** **Why?** When it comes to Remoting issues, it is really hard to diagnose them
** Recently I have published link:[some slides] about preventing and diagnosing issues, but I want the behavior to be more stable by default
** This EPIC lists my plans about Remoting issues and papercuts I would like to fix this year
2. Remoting Work Directories
** For long time logging was disabled by default in Java Web Start (JNLP) and SSH agents, because Remoting had no option to determine where to store such data before connecting to the master
** The new link:[Remoting Work Directory] feature (since Remoting 3.8) offers such storage, which is also used for storing JAR caches and for checking workspace writeability before accepting builds.
** This EPIC is about enabling Remoting work directories by default in common Agent launcher types.
3. Remoting Upgradeability
** Right now Remoting is not being upgraded automatically on JNLP agents, it is supported only for Windows service agents starting from Jenkins 2.50
** On the Jenkins master side it is required to upgrade the Jenkins core in order to pick Remoting fixes.
** This EPIC aims simplifying the upgrade procedure for most common cases.

If you are interested to contribute to these or other activities,
please feel free to reach out to me in the bugtracker or in the link:[#jenkins IRC channel].

If you are coming to Jenkins World, you can also find me at the "Ask the Experts" booth there.
See more info about Ask the Experts link:/blog/2017/08/03/jenkinsworld-ask-the-experts/[here].

## Useful links

* link:[Remoting Sub-Project] on Jenkins website
* link:[Remoting Release Notes]
* link:[Remoting documentation] on GitHub
* link:[My slides] about Remoting issues troubleshooting

0 comments on commit c5f1e65

Please sign in to comment.