remove dependencies to external modules

[timogoebel]

This commit removes dependencies to external services.

They should be defined in a profile module, something like this:

# puppet-katello
Certs::Ssltools::Certutil <| |> ~> Service['qpidd']
Class['certs::apache'] -> Service['httpd']
Class['certs::candlepin'] ~> Service['tomcat']
Class['certs::qpid'] ~> Service['qpidd']

# puppet-foreman_proxy_content
Class['certs::foreman_proxy'] ~> Service['foreman_proxy']

# on a katello:puppet class (which does not exist, yet)
Class['puppet::server::install'] -> Class['certs::puppet']

[timogoebel]

PR agains puppet-foreman_proxy_content: theforeman/puppet-foreman_proxy_content#114

[timogoebel]

PR against puppet-katello: theforeman/puppet-katello#172

[ehelms]

Unfortunately, this exists because Puppet 4 packages do not create a puppet user (unless it's been fixed) in the RPM so we aren't guaranteed this will work at the time of calling without requiring this class here.

[ekohl]

We could let our puppet module manage the puppet user (possibly in puppet::server::config). Then puppet autorequires would fix this for us.

[ehelms]

I think this is a nice cleanup. I do have a question regarding the design change. The intent of the notifies is such that when the certificates change the services would be notified and restarted to ensure they pick up the certificate changes. By dropping that, how do we ensure this functionality?

[ehelms]

Oh I see, you are moving it into the calling module. Which pushes the reload responsibility off to a third party module. I suppose this gives more control to the third party module and pushes the certs module to be more of a certificate manager who doesn't care where and how you use the certs. Thinking out loud :)

[timogoebel]

I suppose this gives more control to the third party module and pushes the certs module to be more of a certificate manager who doesn't care where and how you use the certs.

Exactly. And it makes testing this class easier or would allow users to use this class for something else. :-)

Regarding the puppet dependency: I'm unsure, what's the best way to solve this. The current implementation has the issue, that it relies on the internals of puppet-puppet and the code will fail if a user doesn't use this class to manage puppetserver.
@ekohl : Any idea?

[ekohl]

Are you sure this is correct? Isn't there a chance the key will have incorrect permissions for apache? #137 does solve it by containing the keypair in a define and let that notify apache.

[timogoebel]

I agree, if we actually include ::apache to get the user and group, we should just leave this in.

[ehelms]

I believe @stbenjam filed an issue with Puppetlabs to fix this in their RPM. I don't know the current state but maybe he can inform us.

[stbenjam]

It's unresolved.
https://tickets.puppetlabs.com/browse/SERVER-1381

[ehelms]

Will need a rebase as well

[timogoebel]

Rebased and re-added the puppet dependency and httpd requirement.

[ehelms]

Thanks @timogoebel !