Managing config.xml settings with Augeas

[daenney]

I was looking at how to add support for configuring LDAP authentication which made me stumble across the Groovy helper and the realisation that basically any additional configuration you might want to do will require an update to the helper (and using the CLI).

We've currently implemented a solution by using the Augeas XML lens instead which works well for us (so far). It's a bit nasty in the sense that you know need to know what the XML stanza's look like that you need for the configuration you want to change but you can easily do this by just making the configuration change through the Jenkins UI and then diffing config.xml.

Is there any interest in contributing such a solution?

[jhoblitt]

Hi @daenney,

I am working on a branch with a number of types/providers, including types for configuring the authentication strategy and security realm. It is under active development (read: it is being rebase/squashed daily) and will likely see some refactoring in the next few days as prep for my puppetconf talk titled Puppet vs. Jenkins: A Tale of Types and Providers. I will be at the contributor summit and would be happy to discuss this module and/or help work on features.

This is the branch:

https://github.com/jhoblitt/puppet-jenkins/tree/feature/types_and_providers

I am not planning to implement support for configuring ldap but doing so on top of my cli provider should essentially require filling in this case statement:

https://github.com/jhoblitt/puppet-jenkins/blob/feature/types_and_providers/files/puppet_helper.groovy#L634-L637

[jhoblitt]

In the [likely] event that the line numbers change, look for this comment blurb:

      // XXX not implemented "LDAP"
      //case hudson.security.LDAPSecurityRealm:
      // public LDAPSecurityRealm(String server, String rootDN, String userSearchBase, String userSearch, String groupSearchBase, String groupSearchFilter, LDAPGroupMembershipStrategy groupMembershipStrategy, String managerDN, Secret managerPasswordSecret, boolean inhibitInferRootDN, boolean disableMailAddressResolver, CacheConfiguration cache, EnvironmentProperty[] environmentProperties, String displayNameAttributeName, String mailAddressAttributeName, IdStrategy userIdStrategy, IdStrategy groupIdStrategy)

[daenney]

Hi @jhoblitt, we should certainly get together during Puppetconf. My main "issue" with the groovy_helper powered solutions is that I need to extend it every time I want to set some kind of setting that needs to end up in config.xml, which takes a whole PR+release cycle :disappointed:.

[jhoblitt]

@daenney Definitely! It will be good to see you.

The exact byte for byte format of the configuration files may change slightly between versions of jenkins core and plugins. Sometimes this is whitespace changes but may also be changes to attributes in a tags or new tags are included. jenkins will rewrite it's configuration when restarted, which makes it a struggle to keep external xml configuration idempotent. The configuration format is derived from class constructor parameters. API changes almost always deprecate and preserve the previous constructor. The effect is that the configuration API is stable while the exact config file format is hard to predict.

That said, there are certainly downsides to driving the configuration via jenkins. For example, the service has to be in a working state. And at least plugin installation seems to work better when done "behind" jenkins' back. It certainly should be possible to manage all of the XM external to jenkins. My concern, when I started down the cli provider path in May, was that external management would be "fiddly" and have to be tuned for the exact version of all components. I know there was a parameter change in a plugin I use that I didn't require any puppet side changes because of the API approach. I'm certainly interested to hear what your experience has been?

[daenney]

So augeas doesn't really care about white spaces or the exact location of a stanza in the file. All it does, the way we use it, is to simply check if a node is present. If not, it'll add it according to the instructions given. Jenkins can rewrite that same file as many times as it wants, as long as the nodes are still named as they were before, augeas won't do anything to it.

There is definitely the problem of updates to plugin versions that change their configuration format. However, wouldn't the groovy_helper be affected in the same way? If it isn't updated to know/support a new configuration option in core or plugin, how could it set it?

[jhoblitt]

@daenney Plugin upgrades almost always retain the existing class constructor for compatibility. I recently did this myself for a change to the github-oauth plugin: https://github.com/jenkinsci/github-oauth-plugin/pull/35/files

I have opened a PR for comments on my native types and providers work: https://github.com/jenkinsci/puppet-jenkins/pull/382

[jniesen]

Another problem that I've run into with the cli helper is that our requires the jenkins service to be running. Something that can cause problems when you're baking an AMI for your jenkins master to be deployed without running puppet again.

We've been using packer and the masterless puppet provisioned to do this and a running service can cause problems.

We also went down the augeas path (starting with ldap configuration) and have had some success.

[jniesen]

Sorry, @jhoblitt, I just noticed you mentioned the running jenkins service requirement.