[Pkg-puppet-devel] Notes from the Puppet BoF @ DebConf18

[Apollon Oikonomopoulos]

[ CC'ing everyone I think is not a member of p-p-d ]

Hi all,

This is a summary of what was said in the ad-hoc Puppet BoF we held 
yesterday at DebConf18 (with minor edits/corrections).

The BoF's aim was to bring together people using Puppet on Debian 
systems with members of the Puppet maintainers team and discuss the 
current status and the future of Puppet packages.

Current status
--------------

As of today, the latest stable upstream releases (puppet 5.5.3, facter 
3.11) are available in sid/buster (but not stretch-backports). We still 
use the "old" Ruby master code via rack, together with a rack middleware 
that offers 3.x agent compatibility. Note that upstream has moved away 
from Ruby puppet-masters since 4.x in favor of Puppet Server, but the 
Ruby puppet-master has been working fine for a bunch of us.

PuppetDB 4.4 has been in unstable since DebConf17, but never migrated to
testing for reasons detailed below.

Puppet Server has not been packaged yet and there are no concrete plans 
to do so in the near future, although it should not be too hard after 
PuppetDB has migrated to testing. The only real question is the 
availability and support of the required JRuby versions in Debian.

PuppetDB packaging
------------------

PuppetDB was packaged mostly during last year's DebCamp, in a sprint 
that resulted in ~70 new packages. The package is known to work (or at 
least have worked), but never migrated to testing, at least due to the 
following RC bugs:

  - https://bugs.debian.org/878193
  - https://bugs.debian.org/884186
  - https://bugs.debian.org/825501
  - https://bugs.debian.org/850798
  - https://bugs.debian.org/875365
  - https://bugs.debian.org/880320
  - https://bugs.debian.org/880351
  - https://bugs.debian.org/889125
  - https://bugs.debian.org/896991

Also, most of the Clojure dependencies have been packaged prior to the 
inclusion of leiningen in the archive and should be converted to use 
leiningen for building. To that end, we need to coordinate with the 
Clojure and Java teams, primarily to integrate leiningen with dh.

Towards the freeze
------------------

The Puppet 6 timeline is not concrete yet. According to [1], release is 
expected this fall, which should give us enough time before freeze. No 
major DSL changes are expected; however, upstream says that they will 
try to split built-in puppet types (e.g. like Nagios) into separate 
modules. So far the following types seem to have been removed from 
master and split out to standalone modules:

  - mount (https://github.com/puppetlabs/puppetlabs-mount_core)
  - zfs (https://github.com/puppetlabs/puppetlabs-zfs_core)
  - selinux (https://github.com/puppetlabs/puppetlabs-selinux_core)
  - augeas (https://github.com/puppetlabs/puppetlabs-augeas_core)
  - nagios (https://github.com/puppetlabs/puppetlabs-nagios_core)
  - sshkeys (https://github.com/puppetlabs/puppetlabs-sshkeys_core)
  - cron (https://github.com/puppetlabs/puppetlabs-cron_core)
  - host (https://github.com/puppetlabs/puppetlabs-host_core)

According to [1], these modules will be included in puppet-agent at 
packaging time; it remains to be seen if this includes the official 
tarballs as well, and if not, whether we'll bundle them in the puppet 
package or use individual packages.

Finally, extrapolating from [1], Puppet 5.x should have a good couple of 
years until EOL, so it could still be chosen for Buster, in case Puppet 
6 turns out to be impossible.

[1] https://groups.google.com/forum/#!topic/puppet-dev/uNoCQu6rcFU

As far as Puppet Server is concerned, it is not required to run a puppet 
master. Upstream says the Ruby master code is deprecated and supports 
only Puppet Server, but for the time being the rack master code works 
fine.  Future development might lead to features being available only on 
Puppet Server, so we should keep an eye open. However, for the time 
being, our energy should really be spent on PuppetDB.

While PuppetDB is not a strict requirement, it is still necessary for 
using exported resources, and also acts as a convenient centralized 
information store, which makes it an essential part of every non-trivial 
deployment. Thus we should try to have PuppetDB in buster if possible.
 
Short-term actions
------------------

A number of people offered to help with some of the tasks outlined 
above:

olasd, along with georg, will handle puppet and facter backports to 
stretch.

rbalint offered to reduce the delta with Ubuntu.

olasd and myself will take a look at PuppetDBs clojure dependencies and 
the RC bugs currently blocking puppetdb.

zigo offered to set up #debian-puppet on OFTC

We also got offers from pollo and intrigeri for early testing of new 
Puppet packages.

Finally, I'll update the wiki page [2] both for end-users and packagers.

[2] https://wiki.debian.org/Puppet

If anybody reading these lines would like to help with any of the issues 
above, suggest something else, or just comment, please feel free to 
reply to this e-mail.

/A