Is freeze_main supposed to work this way?

[jcbollinger]

This Puppet 5.4.0 error message wraps up the situation in a pretty tidy package:

Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Evaluation Error: Error while evaluating a Function Call, Cannot have code outside of a class/node/define because 'freeze_main' is enabled (file: /etc/puppetlabs/code/environments/production/manifests/defaults-firewall.pp, line: 14, column: 3) on node redacted.machine.xxx

The freeze_main setting is documented to trap code other than classes, defined type, and node definitions appearing at top scope, other than in the site manifest.  The error message is complaining about a manifest in its environment's site manifest directory, which would not be evaluated at all if Puppet were not treating it as part of the site manifest.  So why is Puppet complaining?  Is this just a straight-up bug, or is there more to it?


John

[Henrik Lindberg]

On 17/04/18 00:10, jcbollinger wrote:
> This Puppet 5.4.0 error message wraps up the situation in a pretty tidy
> package:
>
> Error: Could not retrieve catalog from remote server: Error 500 on
> SERVER: Server Error: Evaluation Error: Error while evaluating a
> Function Call, Cannot have code outside of a class/node/define
> because 'freeze_main' is enabled (file:
> /etc/puppetlabs/code/environments/production/manifests/defaults-firewall.pp,
> line: 14, column: 3) on node redacted.machine.xxx
>
>
> The freeze_main setting is documented

> <https://puppet.com/docs/puppet/5.5/configuration.html#freezemain> to

> trap code other than classes, defined type, and node definitions

> appearing at top scope, /other than in the site manifest/.  The error

> message is complaining about a manifest in its environment's site
> manifest directory, which would not be evaluated at all if Puppet were
> not treating it as part of the site manifest.  So why is Puppet
> complaining?  Is this just a straight-up bug, or is there more to it?
>

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.

- henrik




--

Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/

[jcbollinger]

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

[Henrik Lindberg]

On 17/04/18 16:46, jcbollinger wrote:
>
>
> 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:
>
> |
> iflookup('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.
>

It is PUP-8637 if you want to try with a version that has the fix.
I believe it was actually the Firewall module that triggered the problem
reported in that ticket.