Installing plugins fails jenkins-bootstrap-start

[jtreminio]

Using your instructions in README.

Attempting to install any plugin triggers this issue.

I've attempted on your v1.6.1 tag as well as master.

Output:

/Stage[main]/Jenkins::Plugin[git]/Archive[git.hpi]/ensure: download archive from https://updates.jenkins-ci.org/latest/git.hpi to /var/lib/jenkins/plugins/git.hpi  without cleanup
==> jenkins1: Info: /Stage[main]/Jenkins::Plugin[git]/Archive[git.hpi]: Scheduling refresh of Service[jenkins]
/Stage[main]/Jenkins::Plugin[git]/File[/var/lib/jenkins/plugins/git.hpi.pinned]/ensure: created
==> jenkins1: Info: /Stage[main]/Jenkins::Plugin[git]/File[/var/lib/jenkins/plugins/git.hpi.pinned]: Scheduling refresh of Service[jenkins]
/Stage[main]/Jenkins::Plugin[git]/File[/var/lib/jenkins/plugins/git.hpi]/owner: owner changed 'root' to 'jenkins'
/Stage[main]/Jenkins::Plugin[git]/File[/var/lib/jenkins/plugins/git.hpi]/group: group changed 'root' to 'jenkins'
/Stage[main]/Jenkins::Service/Service[jenkins]: Triggered 'refresh' from 2 events
/Stage[main]/Jenkins::Cli/Exec[jenkins-cli]/returns: executed successfully
/Stage[main]/Jenkins::Cli_helper/File[/usr/share/jenkins/puppet_helper.groovy]/ensure: defined content as '{md5}30fa64840c6dbd5005635888fd9bff2f'
/Stage[main]/File[/usr/share/jenkins/jenkins-bootstrap.sh]/ensure: defined content as '{md5}a6b05fc02cfcb273cc0bdbf322cb2df7'
/Stage[main]/Exec[jenkins bootstrap file]/returns: java.io.IOException: No X-Jenkins-CLI2-Port among [X-Jenkins, null, X-Hudson, X-Hudson-Theme, Content-Length, Expires, X-Jenkins-Session, Set-Cookie, Content-Type, Server, Cache-Control, X-Content-Type-Options]
at hudson.cli.CLI.getCliTcpPort(CLI.java:290)
at hudson.cli.CLI.<init>(CLI.java:128)
at hudson.cli.CLIConnectionFactory.connect(CLIConnectionFactory.java:72)
at hudson.cli.CLI._main(CLI.java:479)
at hudson.cli.CLI.main(CLI.java:390)
Suppressed: java.io.IOException: Server returned HTTP response code: 503 for URL: http://127.0.0.1:8080/cli
    at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1628)
    at hudson.cli.FullDuplexHttpStream.<init>(FullDuplexHttpStream.java:78)
    at hudson.cli.CLI.connectViaHttp(CLI.java:158)
    at hudson.cli.CLI.<init>(CLI.java:132)
    ... 3 more

Omitting plugins avoids the issue and Jenkins is setup properly.

Running Puppet again after initial run also seems to skirt issue completely.

[jhoblitt]

@jtreminio The resource that is failing (Exec[jenkins bootstrap file]) in your output is not part of this module.

[jtreminio]

@jhoblitt it simply contains the bash code you have on README:

file { "${jenkins_libdir}/jenkins-bootstrap.sh":
  ensure  => present,
  owner   => 'jenkins',
  group   => 'jenkins',
  mode    => '0764',
  content => template($bootstrap_script),
} ->
exec { 'jenkins bootstrap file':
  command => "${jenkins_libdir}/jenkins-bootstrap.sh",
  creates => "${jenkins_libdir}/jenkins-bootstrap.done",
  group   => 'jenkins',
  user    => 'jenkins',
  path    => [ '/bin', '/usr/bin' ],
}

---

#!/bin/bash

# Generate an SSH key for the admin user
ADMIN_USER='<%= @admin['username'] %>'
ADMIN_EMAIL='<%= @admin['email'] %>'
ADMIN_PASSWORD='<%= @admin['password'] %>'
ADMIN_FULLNAME='<%= @admin['full_name'] %>'
ADMIN_SSH_KEY='<%= @admin['ssh_keyfile'] %>'
JENKINS_CLI='<%= @jenkins_libdir %>/jenkins-cli.jar'
PUPPET_HELPER='<%= @jenkins_libdir %>/puppet_helper.groovy'
HELPER="java -jar ${JENKINS_CLI} -s http://127.0.0.1:8080 groovy ${PUPPET_HELPER}"

ADMIN_PUBKEY="$(cat ${ADMIN_SSH_KEY}.pub)"

# Create the admin user, passing no credentials
${HELPER} create_or_update_user "${ADMIN_USER}" "${ADMIN_EMAIL}" \'"${ADMIN_PASSWORD}"\' \""${ADMIN_FULLNAME}"\" "${ADMIN_PUBKEY}"

# Enable security. After this, credentials will be required.
${HELPER} set_security full_control

Please reopen, I believe the issue lies with the module.

[jhoblitt]

That bootstrap script will only ever work once. After authentication is enabled, it will always fail. The new experimental types should not suffer from the difficulties with auth being enable/disabled but as it says on the tin, are in an experimental state. https://github.com/jenkinsci/puppet-jenkins#experimental-types-and-providers

[jtreminio]

I understand, but this doesn't really involve the issue I'm seeing.

This code runs perfectly if no Jenkins plugins are to be installed. If any plugin is installed, then this fails.

If the above is run, then Jenkins plugins installed in a later Puppet run, it succeeds.

[br0ch0n]

@jtreminio you're not crazy. Installing plugins at initial run definitely somehow causes different behavior than not (it blocks/messes up the cli port with the IOexception you mention above) will let you know if I figure out why

[jtreminio]

@jhoblitt would you mind reopening this issue?

[jhoblitt]

@jtreminio Sure - a complete working manifest might help someone debug this. However, my suggestion is look at using the experimental native types which are a complete solution to the authentication issues. They need more usage before we can think about stabilizing them.

[br0ch0n]

For what it's worth, I worked around this by just adding more tries to my exec. No idea what the actual problem with the cli is, but I imagine it's its own issues, not really the puppet module.

[jhoblitt]

It could be just timing issues with jenkins not being ready. There's really no way to debug this. I'm going to close this issue since the code in question is external the module but I would be happy to merge a PR updating the README.