semi-regular triage/use case discussions?

[jhoblitt]

Would folks be interested in holding semi-regular triage/use case discussions? The primary agenda would be to beat down the issue/PR backlog and discussion of the primary use cases going forward and how this module should evolve.

[esalberg]

I am interested in triage and use case discussions.

Summary: We switched to using Docker because of bootstrap issues, and would need to have LDAP auth (not a big deal with the types/providers) and safe restart added at minimum to consider switching back. A hybrid Docker install / Puppet config management (since the config files are stored persistently) option would be great as well.

Details on our use cases:

1. Bootstrap new Jenkins instance on RHEL 7 with authentication / authorization configured (in our case, LDAP + role based plugin), no security warnings
   -- We currently do this with the Docker image + /etc/init.d/groovy script (for LDAP) + initial config.xml (for role based az - until I figure out the groovy script to configure it more directly)
2. Install / update plugins (either some variety on plugins.txt, or the other methods being discussed)
   -- We currently do this via the Docker image by passing plugins.txt to install-plugins.sh as provided with the image
   -- For configuring plugins, I've put bootstrap xml files into git and pull them down for a new instance using vcsrepo. This isn't ideal for sure.
3. Use safe restart for updating plugins, etc.

We currently have groovy init scripts to set the default e-mail address and smtp settings, set executors, setup LDAP auth, and harden against security warnings (no remoting, prevent CSRF, etc.). Providing a process to add in groovy scripts (e.g. like the sudoers or logrotate modules) might be useful - although I get nervous that theses are post-initialization scripts only and won't get run for a while - maybe they should refresh the Jenkins service (with safe restart) on a change?

Some thoughts:

1. What about a use case where Jenkins runs in a container (bootstrap managed by groovy scripts; plugin installation via the install-plugins.sh script) but Puppet is used to lock down / configure jobs, credentials, etc.?

• With the Docker image, I'm less concerned about relying on the groovy init scripts, as the container should be reloaded regularly anyway.

I like the Docker image, but have been considering switching back because of Production lock-down requirements from Security that makes configuring jobs via Puppet attractive. Another alternative might be using vcsrepo to pull in jobs from git.

[esalberg]

I ran through the open PRs and most of the open issues for triage. I'd really like to get the automatic Travis checks in place again, though, before pushing any of these through.

(Review PR standards - e.g. squash to one commit, doc update, either specify or validate type for variables, spec tests, etc. - also see issues #393, #394, #397, #718 )

Top design issues:

1. Stop accepting new non-native type changes (e.g. PAM auth, LDAP auth, user changes) - require those to be implemented as the native types and providers only?

2. Management of init.groovy.d scripts - how do we want to do that? Should be flexible to allow users to add their own scripts via template / hiera / etc. What about running groovy scripts not at initialization time? Should init.groovy.d script changes call a (safe) restart of Jenkins?

• also issue Groovy helper scripts should be abstracted out of the repo #230 to abstract groovy helper scripts, issue Jenkins restart service doesn't support safe restart #368, fancy restarts #534 for safe restart

3. Plugin management
   Issues: Add ability for removing jenkins plugin #10 Jenkins Puppet Package provider discussion #12 Error in plugin version check algo? #192 Jenkins::Plugin should respect installed plugins, support ensure => latest #309 jenkins::plugin only manages .pinned & .disabled files when changing versions #521 plugin resources don't install dependency's #677 PLUGIN: upgrade doesn't work for some reason #731 Acceptance tests related to plugin installations (or that require a plugin installation) are not failing/succeeding consistenly. #839 Rework / rethink the way we are dealing with plugins (and their dependencies) #841

4. CLI / remoting / bootstrap access issues, e.g. issue Initial setup fail to create user - ERROR: anonymous is missing the Overall/Read permission #684 (unclear if this is mainly the Debian issue), issues puppet_helper.groovy uses deprecated remoting mode #749 Deprecated cli access, unable to set initial admin account #808 legacy CLI.jar remoting is broken #814 revert new CLI interface #854 (discussion of reverting remoting cli changes)
   work with elconas to get those changes reviewed / implemented

5. Other: Issues related to the native types/providers probably should be prioritized if they're not going to be considered experimental (e.g. Got java.io.IOException: Stream closed when calling jenkins_security_realm #730).

• Also need better documentation / examples of the native types / providers (especially bootstrap / security related), config_hash, etc.

---

The following look like they are pretty easy changes after review / rebase / squash to one commit / add tests. However, not sure what the etiquette is related to taking other people's PRs and resubmitting them.
#432 #436 #439 #555 #593 #725 #811

These are more complex but look close to being complete:
config.xml (#508) and plugin templates (#592)

• see also issue Managing config.xml settings with Augeas #381

---

Native type/provider enhancements:
LDAP auth (#339 #606, issue #332 ) - implement with native types/providers; need to be able to encrypt password if applicable
PAM auth (#809) - implement with native types/providers
New jenkins_exec (script/groovy) type #791

User management issues (idempotency #504), (password update #524), (bootstrapping secure users #761 #824)

• requires init.groovy.d discussion; implement with native types/providers; discuss if Check password to see if it's changed when adding/updating credentials. #524 is a bug fix

java args / sysconfig fixes: #723

• issue Add support for a custom JAVA_HOME #217 JAVA_ARGS escaping issue #448 may also be related; issue $user setting in init.pp#L203 not set/used in /etc/sysconfig/jenkins #634

OS issues - each needs someone using the specific OS to take it on:
OpenBSD support (PR #304 #658 #743); also issue #105 for FreeBSD
Windows support (PR #466 #816)
MacOS script (PR #780)
Debian - Related to issue #462?

---

Possibly should be closed:
#456 (fact no longer exists?); #472 (comments state that the functionality already existed?)

• there are a number of issues that look like they are ready to be closed, although some should be documented first

Currently active PRs (updated within the last 2 weeks):
#844 (spec tests; waiting rebase)
#484

[rnelson0]

I am in favor of regular triage calls, maybe every 2 weeks while we hammer out the post-transfer issues before moving to a monthly schedule.

[rnelson0]

@jhoblitt next Monday would be two weeks from the prior triage, did you want to set that up as the first recurring meeting?

[ekohl]

Right now this isn't happening anymore so I'm closing this.