Add puppetdb support

[mcanevet]

For the moment you can't enable both foreman and puppetdb because of duplicate Class['postgresql::server'] resource.

[GregSutcliffe]

Hmm, I'm not convinced we want to add puppetdb support to our installer - it seems like the sort of thing only more advanced users want. For a basic foreman/puppet setup, it seems overkill. Can we fix the duplicate resource some other way?

[GregSutcliffe]

Mmm, that sounds way too negative :) For the record, I'm happy to discuss puppetdb support, just not sold on it yet. @ekohl @domcleal thoughts?

[skottler]

I'm not particularly against adding puppetdb support, but I don't think it should be installed by default, which seems to be the case right now. @mcanevet - would you mind explaining the workflow of using both puppetdb and foreman in tandem?

[mcanevet]

@skottler , @GregSutcliffe , @domcleal first I launched installation with default answer.yaml, then launched it again by adding:

puppetdb:
  manage_redhat_firewall: false
puppetdb::master::config:
  restart_puppet: false

and disabling foreman (foreman: false) because of duplicate Class['postgresql::server'] resource

[GregSutcliffe]

There doesn't seem to be any interdependance between the puppetdb modules and our modules - as such, I'm not clear why a user couldn't just add the appropriate puppetdb modules to his setup at a later time. We could document how to avoid the postgresql clash though...

[ekohl]

As someone who uses puppetdb I highly welcome this. We currently run puppetdb on a separate server so we haven't ran into any issues, but I can see the added value for the installer to support this.

In the long run I could even see foreman using puppetdb for facts and reports instead of its own database.

[domcleal]

I'm indifferent to including it - on the one hand it's more to maintain for a project Foreman doesn't use, but on the other I agree with @ekohl that it could be used in the future, plus it's a common tool that doesn't conflict with Foreman and we should encourage the use of alongside.

I would not want to include it if the modules aren't integrated though, we shouldn't ship an installer that doesn't work in one run. Needing to re-run with different settings (due to PostgreSQL conflict) and then not being idempotent (due to using puppetdb::master::config to edit puppet.conf) is insufficient.

In my setup I use the two together, by adding puppetdb::server (to prevent configuration of PostgreSQL), puppetdb::master::config (with manage_storeconfigs = false), set the storeconfigs parameters on our puppet module and then add a class of my own to add the PuppetDB database. We should be able to do something similar here so the modules play nicely together.

[skottler]

I thought about this a bunch today; the more I do so, the less I think it makes sense to include puppetdb in our installer. The mission of the installer, in my opinion, is to provide a complete, operational Foreman installation with the pieces that are necessary for provisioning (TFTP, DHCP, DNS) in some cases. Under this reasoning, puppetdb shouldn't be included in the installer; it's not needed to get a completely working installation.

👎 from me for this reason.

[ekohl]

I agree with @domcleal that further integration should be done. You should also set $puppet::server::storeconfigs and $puppet::server::storeconfigs_backend. Then I think you could even ignore the puppetdb:master::config since puppet::server will ensure the correct settings as well.

[GregSutcliffe]

I'm with @skottler - although not quite for the same reasons. I don't mind optional parts (we already have dns/dhcp for example), but those are directly related to Foreman. This is an optional part of Puppet which is not required to make Foreman work. As we also want to make Puppet itself optional (we've already got to the point where you don't actually need a puppet master) then I see no reason to add an optional component of an optional component. It's simply not required - this is the Foreman installer, not the Puppet installer.

That said, I'm totally in favour of fixing compatibility issues so that an advanced user can just drop in the puppetdb modules into the same modulepath as the installer later on - assuming it's possible to fix it ;)

[domcleal]

@ekohl you'll still need puppetdb::master::config to deploy routes.yaml IIRC, but I turn off its management of puppet.conf (via inifile) and set the storeconfig params on the puppet module as you say.

[ekohl]

Since @GregSutcliffe and @skottler both prefer to keep the installer light, I'm wondering how we can make it easier to make them play nice together. What we @oxilion do is have our own environment and use all the foreman-installer submodules except foreman-installer to maintain our foreman server, foreman smartproxies and our puppetdb server. Maybe the solution would be to work to a similar environment as the foreman recommended basis? That would most likely involve publishing modules on the forge and leveraging puppet-librarian to build an environment.

Perhaps I'm getting a bit off topic here, but I would like to set up foreman including registration of the smart proxy and add the foreman server to itself as an installer option. Then maybe the installer answers file could be converted into a working puppet environment and all answers applied to the foreman host as class parameters. From there on adding a puppetdb server would be pretty similar to adding any other puppet module.

Since I'm now at DjangoCon I don't have the option to try properly test the options, but I did think this was important enough to at least dive into the discussion.

[ekohl]

Last week I tried setting it up on one host and noticed that I have to include the puppetdb setup before foreman since puppetdb uses class{'postgresql::server'] where foreman uses include postgresql::server. Thought this was the best place to document it for now.

[GregSutcliffe]

Discussion has stalled on this somewhat, but it seems the broad consensus is to make some changes to improve interoperability, but not directly include puppetdb in the installer. On that basis, I propose we open a redmine issue to discuss the necessary changes, and close this PR. Thoughts?

[skottler]

A mail to the -dev list might get better feedback than redmine, but I support the concept of having a more broad conversation. Feel free to close this for now @GregSutcliffe 👍

[GregSutcliffe]

Further discussion at http://projects.theforeman.org/issues/2993 - closing this as agreed.