fix ca_cert::update in resource ca_cert::ca

[basti-nis]

due to the bug:
Could not find resource 'Class[Ca_cert::Update]' in parameter 'notify' at /etc/puppetlabs/code/environments/*******/modules/ca_cert/manifests/ca.pp:98
on puppetrun if only following code is declared in the .pp-file:

ca_cert::ca { '':
ensure => 'trusted',
source => "puppet:///modules/standard/ca_cert/",
}

[basti-nis]

I ran in following error on puppet run:
Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Could not find resource 'Class[Ca_cert::Update]' in parameter 'notify' at /etc/puppetlabs/code/environments//modules/ca_cert/manifests/ca.pp:98 on node xxxxxx

This code is declared in the node.pp:
ca_cert::ca { 'xxxxxxxx':
ensure => 'trusted',
source => "puppet:///modules/xxxxxx/ca_cert/xxxxxxxxx",
}

I've checked the code in ca.pp and add the line:
include ::ca_cert::update

after that it's working

[pcfens]

Thanks for thinking this through @basti-nis. I think that this might need more of a documentation fix than a code change though. It's best that include ::ca_cert be dropped somewhere in the main manifest before any ca resources are declared.

The base class also ensures that the right packages are installed for puppet to manage CAs on a particular host.

Thoughts?

[greatflyingsteve]

If the module is incompatible with part of your fleet (say you have some oddball Windows or AIX or Solaris hosts, or some hosts use a different module to manage their CA certs), then dropping an include into the main (and thus, global) manifest is infeasible. If multiple ca_cert::ca resources are used in different places in a host's catalog, it can also be difficult to know where to add an include ::ca_cert so that the catalog isn't parse-order dependent. If you know inside the define that it will not work without an ancillary class, it is better to do an include of that class in the body of the define than to ask the user to do that for you - although it might be better in this case to include the module's base class than to include just the update class. If configuration other than default is needed first, THEN ask the user to include the class first themselves. Or at least, that's how it seems to me.

[greatflyingsteve]

...of course, I say all this, then look at the most recent release and it's already a solved problem. Nevermind!

[h-haaks]

Fixed by #79