Remoting work dir configuration of JNLP Launcher

[Glenn Burkhardt]

Jenkins ver. 2.108, Libvirt Slaves plugin 1.8.5 

I'm trying to get a slave windows client running in a VM under 'libvirt' to start properly.  I've identified the problem to be the same as described in https://issues.jenkins-ci.org/browse/JENKINS-47834.

The problem is that the "slave-agent.jnlp" generated by Jenkins omits the argument for "-workDir" and "-remoteDir".

I've been trying to understand how the "slave-agent.jnlp.jelly" script generates the file, and I suspect that the script and the Libvirt plugin are out of sync.  In particular, there's a reference in the script to "launcher.workDirSettings.workDirPath".  But the VirtualMachineLauncher class defined in the plugin doesn't contain a 'workDirSettings' field.  The delegate does, and the debugger indicates that it's a JNLPLauncher class.  

I see a line in the script that says:

<j:set var="launcher" value="${it.delegatedLauncher}"/>

Does that somehow get mapped to the delegate field in the VirtualMachineSlaveComputer class, which is what the 'it' argument passed to EncryptedSlaveAgentJnlpFile turns out to be.

Also, how does one debug a jelly script like "slave-agent.jnlp.jelly"?  I can't find it anywhere in my deployed Jenkins system.

Thanks.

[Oleg Nenashev]

The ticket has been created to a wrong component, so it has never been triaged. I will the components.
From what I see the Libvirt plugin inherits standard Agent's UI, so the new Jenkins core tries to generate JNLP with workDir.

Also, how does one debug a jelly script like "slave-agent.jnlp.jelly"?  I can't find it anywhere in my deployed Jenkins system.

Please see https://wiki.jenkins.io/display/JENKINS/Figuring+out+URL+binding+of+Stapler
 

[Glenn Burkhardt]

So, how do we get a copy of the libvirt plugin compiled against the current Jenkins core code?  It looks like the libvirt plugin was compiled against jenkins-core-1.625.3.jar, and the JNLPLauncher class didn't contain a "RemotingWorkDirSettings workDirSettings" field at that time.  It might be that simply re-compiling against a more current version of core Jenkins code will fix it.

I've been trying to do that, but I'm new to Maven, and it's not clear to me yet how to force the build to use a more current Jenkins release.

Thanks!

[Oleg Nenashev]

I doubt that recompiling will help.

The problem is with VirtualMachineLauncher. It implements ComputerLauncher, but it does not contain the requested fields as described. But I think it does not block VirtualMachineSlaveComputer and VirtualMachineSlave from inheriting UI of the standard launcher as you pointed in the code. It may be a defect in the core, because there are other similar reports. Obviously the best way would be to just take ownership of the plugin and facelift it to support Work directories... but it should not break.

Could you please create a separate ticket to LibVirt plugin? I will forward it to my colleagues who may be interested to investigate it

I've been trying to do that, but I'm new to Maven, and it's not clear to me yet how to force the build to use a more current Jenkins release.

 Unfortunately libvirt Plugin uses an old Parent POM (1.580). In Parent POM 2.x we have added a support of "jenkins.version" property which allows building custom Jenkins versions. So you could use Parent POM 3.6 and build for Jenkins 1.625.3 or 2.107.1 depending on your needs. But the plugin needs an update to do that.

[Glenn Burkhardt]

I've created an issue:  https://issues.jenkins-ci.org/browse/JENKINS-50427

Thanks for your attention.

I understand the attractiveness of plugins, but using them does raise an issue of maintenance and compatibility.  Perhaps the plugins should be included in the build of Jenkins so problems can be identified.  And also, once an incompatibility has been recognized, that the documentation in the wiki could include the latest version of Jenkins with which the plugin is known to work.  In order to reduce the burden on the core maintainers, once an incompatibility is recognized, the plugin could be dropped from the build until interested parties bring it up to rev.

[Oleg Nenashev]

We have some flows to verify compatibility of Jenkins LTS versions with plugins.
E.g. https://github.com/jenkinsci/acceptance-test-harness/

But Libvirt Agent plugin is not included there AFAICT.

So far it is not confirmed whether it is a plugin defect or regression in the core. I assume the first options taking my rusty knowledge about this part of the codebase. But the issue needs a triage to say for sure.

BR, Oleg

[Glenn Burkhardt]

Thanks for the tips.  I was able to get to work with a few changes to the libvirt-slave code.  I'm not set up to contribute to Jenkins, but I've attached the files that I changed.  There're unchecked casts in the new methods for VirtualMachineLauncher, so probably the 'delegate' field should be changed to have JNLPLauncher type, but I haven't checked how that works with the rest of the code.

There were many errors reported by the static analysis.  Presumably all that should be fixed.

But I have my Windows guest in a libvirt VM running the slave agent as a service now.

[Joseph P]

Any GitHub user can fork a repo and create a branch on that fork. So fork, commit, push, create pull request to the Jenkins repo.
https://guides.github.com/introduction/flow/

/Joseph