On Tuesday, April 17, 2018 at 12:57:19 AM UTC-5, Henrik Lindberg wrote:
> I just fixed a bug regarding freeze_main that was found when an
> autoloaded class/define made use of a not already loaded custom data
> type. The logic raising the error was too simplistic in its check for
> the condition under which it should raise an error.
>
> If your problem is not an actual problem, it may be that you ran into
> that bug.
>
I'm afraid that my problem is a *bona fide* problem in the sense that I
really am trying to use freeze_main, and when I turn it on, catalog
building really fails on my real production manifests.
The line number reported in the error message corresponds to the first '
include' call in the below:
if lookup('with_firewall_iptables', Boolean, 'first', true) {
include '::sb::iptables::fw_pre'
include '::sb::iptables::fw_post'
Firewall {
require => Class['::sb::iptables::fw_pre'],
before => Class['::sb::iptables::fw_post'],
}
}
, and this is modeled pretty closely on the recommended usage of the
puppetlabs/firewall module. Only comments and blank lines precede the 'if',
which appears at top scope, and nothing follows it in the same manifest.
That doesn't strike me as corresponding very well to the bug you described,
but it's difficult for me to be confident about that.
As a workaround, I have simply turned freeze_main back off. Catalog
building then succeeds, and the resulting catalog has the effect I want. I
would prefer to enable freeze_main for an extra level of safety and bug
detection, but not being able to use it does not constitute a major
roadblock.
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/f84d591e-8b56-469d-9ea8-3e428c53e7cf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
