Why is a variable in a `require`d module not always available?

Question

I've got three module manifests in separate files (stripped down to bare essentials):

class users {
  $user = 'foo'

  user { $user:
    ensure => present;
  }
}

class dvcs_cli {
  require users

  file { "/home/${::users::user}/.gitconfig":
    ensure => present,
    source => 'puppet:///modules/dvcs_cli/.gitconfig';
  }
}

class shell {
  require users

  file { "/home/${::users::user}/.bash_aliases":
    ensure => present,
    source => 'puppet:///modules/shell/bash_aliases.sh';
  }
}

.gitconfig is created in /home/foo as expected, but .bash_aliases is created in /home:

$ sudo /usr/bin/puppet apply --modulepath modules --detailed-exitcodes --hiera_config=hieradata/hiera.yaml manifests/host.pp || [ $? -eq 2 ]
[…]
Notice: /Stage[main]/Shell/File[/home//.bash_aliases]/ensure: defined content as '{md5}[…]'
Notice: /Stage[main]/Shell/File[/home/foo/.gitconfig]/ensure: defined content as '{md5}[…]'

It's as if ${::users::user} evaluates to the empty string in one module, but not in the other. How is this possible?

Running with --debug revealed a possible issue: User[foo] is autorequired for dvcs_cli, but not for shell:

$ grep 'Adding autorequire relationship with User' puppet.log | grep -i -e dvcs_cli -e shell
Debug: /Stage[main]/Dvcs_cli/File[/home/pair/.gitconfig]: Adding autorequire relationship with User[pair]

This contradicts the manual, which says:

If Puppet is managing the user or group that owns a file, the file resource will autorequire them.

Could this be related to the "Autorequire relationships are opaque", caused by the fact that both files are in the same directory? And shouldn't autorequires be irrelevant anyway, since both modules explicitly require users?

Running

$ puppet --version
4.2.1

on

$ cat /etc/redhat-release 
Fedora release 24 (Twenty Four)

score 0 · Answer 1 · answered Mar 24 '23 at 11:44

I ran into this in an odd situation, and for me it was Puppet silently breaking a cycle, but not in a predictable way (nor in --debug output). I saw this behavior once before but it 'went away' after some other changes so I never really understood.

Scenario:

class a {
  include b
$foo = 'quick'
  $bar = $b::baz
}
class b {
  include a
$baz = 'brown'
if ($hostname == $baz) {
    $qux = $a::foo
  }
}

here $bar was undef after changing class c that included both a and b conditionally - yet both a and b were untouched. This appears to be incorrect behavior.

The workaround was:

class b {
  $baz = 'brown'
if ($hostname == $baz) {
    include a
    $qux = $a::foo
  }
}

And then $bar was defined again. There's a way to visualize cycles with dot files but I haven't gone that deep into it.

Puppet 5.5.22 (Debian stable)

Why is a variable in a `require`d module not always available?

1 Answers1