Problem

Users of Jenkins who use configuration management tools like chef/puppet/ansible want to manage Jenkins and its configuration entirely from those tools. The motivation for this "configuration as code" practice is well understood — see this for one example.

Today some efforts exist, such as Puppet Jenkins module, but according to its maintainers, Jenkins don't behave well for this purpose.

Proposal

My proposal is to take the success of Job DSL plugin and expand the same idea to other configuation of Jenkins. That is, we define a DSL that allows users to configure such things like security realm, slaves, credentials, clouds, and other global configurations.

Such DSL definitions can be placed under $JENKINS_HOME/init.groovy.d so that it gets executed during the boot.

Jenkins used in this mode should also refuse to show the system configuration page, do not write $JENKINS_HOME/config.xml and other global configuration files from Descriptor, and generally do not allow users to make changes in GUI for parts that are coming from the initialization DSL script.

With something like this, Puppet/Chef/Ansible now only needs to lay down files inside $JENKINS_HOME. Combined with Job DSL plugin, the entire Jenkins deployment can be fully managed by code.