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. On Tuesday, March 27, 2018 at 8:32:24 AM UTC-4, Oleg Nenashev wrote: > > 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 > > On Tuesday, March 27, 2018 at 2:22:49 PM UTC+2, Glenn Burkhardt wrote: >> >> 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. >> >> >> On Tuesday, March 27, 2018 at 4:15:13 AM UTC-4, Oleg Nenashev wrote: >>> >>> 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. >>> >>> >>> On Monday, March 26, 2018 at 11:39:38 PM UTC+2, Glenn Burkhardt wrote: >>>> >>>> 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! >>>> >>>> On Saturday, March 24, 2018 at 9:42:57 AM UTC-4, Oleg Nenashev wrote: >>>>> >>>>> 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 >>>>> >>>>> >>>>> On Friday, March 23, 2018 at 6:46:03 PM UTC+1, Glenn Burkhardt wrote: >>>>>> >>>>>> Jenkins ver. 2.108 <https://jenkins.io/>, 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. >>>>>> >>>>> -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/23c7f4df-52f5-4c92-9d23-72fb87d77811%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
libvirt-fix.tar.xz
Description: Binary data
