add PuppetDB configuration on puppet master side #182
Conversation
|
We've had some discussion about this in the past and while personally I'm not against this, others were. See theforeman/foreman-installer#46 for some history. You will also need to set the reporting, storeconfigs and storeconfigs_backend if you want full integration. |
|
There are already options for Regarding the integration, we also had a short talk on IRC about that, my desire here is to get support for configuring a Puppet master to talk to PuppetDB into our puppet-puppet. Regarding the possibility of pulling in support to install/configure PuppetDB itself, personally I would love it, as foreman-installer could then also be used to automate away that task in the same way as Foreman (without a Puppet master) and Puppet (master, with connection to Foreman on another host) itself, but that duplicate postgresql include and pulling in puppetlabs-inifile without further usage don't seem to be worth it at the moment. |
I don't know what I want ;) Just considering the options at this point. |
|
I didn't implement it, because it's just easier by leaving it as-is ;) |
|
Regarding PuppetDB support in the installer generally, I'm less indifferent now and am more keen to include it - particularly as we've gained other optional bits and kafo has improved the installer since the last PR was opened. That said, I think other Foreman developers are less keen to make use of PuppetDB and similar tools than I am. Regarding this PR specifically, I think it overlaps too much with puppetdb::master::config, which does a better job. The only thing that might be preferable in puppet-puppet is routes.yaml as it's a generic config file, but there aren't many uses for creating and configuring it. Edit: my conclusion is, do it, but use the official puppetdb module instead of duplicating it, and let's figure out how to make them play nicely together automatically. |
|
Updated WIP, now using puppetlabs-puppetdb. That seems to work, storeconfig_backend and reports have to be set to puppetdb seperately to use all these, respectively. Comments? |
|
I wonder if there should be an |
|
Not yet. That would be the next step, after managing the Puppet master side. |
|
rebased |
|
I wouldn't be against this, but I'm hesitant to add it as an unconditional dependency. I'm leaning to doing so because IMHO PuppetDB is a valuable addition in many cases. |
|
now with added test. no idea what's going on with 2.7 there... |
|
I wonder if a gem broke compatibility with 2.7. |
|
I messed up metadata.json. All 馃挌 now |
|
Maybe add a test to the 'with no customer parameters' that it should not contain the puppetdb class? Other than that there's a puppetlabs recommendation that for soft dependencies it should be in README rather than metadata.json. See #162 (comment) as well. |
|
all done, I think |
|
馃憤 from my side. @domcleal? |
|
needed a rebase again |
| class { '::puppet': | ||
| server => true, | ||
| server_puppetdb_host => 'mypuppetdb.example.com', | ||
| server_reports => 'puppetdb', |
There was a problem hiding this comment.
Nitpick, should we keep 'foreman' in here too?
There was a problem hiding this comment.
As foreman got optional, I presume not, but I wouldn't mind having it also in just as example.
There was a problem hiding this comment.
I do think people will be surprised if suddenly they don't have foreman reports anymore so I'd prefer having it in the example.
There was a problem hiding this comment.
And just now I see it was already merged.
There was a problem hiding this comment.
Ah, sorry. Please feel free to push it straight to the repo, I guess it'd be server_reports => 'puppetdb,foreman'
There was a problem hiding this comment.
No problem, it's just a minor comment :)
|
Otherwise 馃憤 |
|
updated |
|
Merged, thanks @mmoll! |
more a WIP for discussion. comments please 馃摪