Could not parse for environment production: Cannot assign to variables in other namespaces

[JeremyCampbell]

We're trying to set a role variable in one of our role classes i.e.

class role::nameserver {
 
  $::role = 'nameserver'

  include profile::baseline
}

however we get the following error

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Could not parse for environment production: Cannot assign to variables in other namespaces

We do not get the error if we just use

 $role = 'nameserver'

Does anyone understand what is causing this?

[badgerious]

Take a look at the last paragraph here: http://docs.puppetlabs.com/puppet/3/reference/lang_variables.html#assignment

$role = 'nameserver'

assigns a variable within the 'role::nameserver' namespace (allowed), while

$::role = 'nameserver'

assigns a top level variable (not allowed).

Eric

[JeremyCampbell]

Eric, thanks. I've spent most of today trying to get this to work but I have to submit again. I've read the linked docs on variables multiple times. As I understand it, with Puppet you cannot assign top-level variables i.e. starting with $::, these are reserved for facts and other built in Puppet values. So I assign $role = "nameserver" in the role::nameserver class - this works and I get no errors. However no matter what I do hiera doesn't recognise the variable as shown below.

- "%{::environment}/%{::clientcert}"
- "%{::clientcert}"
- "%{::environment}
- "%{role}"
- common

Any ideas what could be causing this?

[Mike Delaney]

If you're assigning $role inside the role::nameserver class, then its scope is limited to just role::nameserver (and any classes
that inherit from role::nameserver)[1]. So, hiera lookups from inside role::nameserver will see that level of your hierarchy, but
it will be invisible almost everywhere else. I say "almost" because if you have some other class or defined type that just happens
to assign a value to a local variable named $role, hiera lookups from within its scope will see that as well, which can lead to
all sorts of fun. That's why the hiera docs caution against using local variables to define your hierarchy[2].

If I understand correctly, what you're really trying to achieve here is to be able to use a node's "role name" in your hierarchy, yes?
For that, you really want a variable up at top scope, but how to set it? How are you associating your role classes with your nodes?
If you're using an ENC, you could have it return the role variable assignment (variables set in the ENC are included in top scope).

-Mike

[1] http://docs.puppetlabs.com/puppet/3/reference/lang_scope.html
[2] http://docs.puppetlabs.com/hiera/1/puppet.html#best-practices

[jcbollinger]

On Friday, August 23, 2013 11:33:14 AM UTC-5, JeremyCampbell wrote:

Eric, thanks. I've spent most of today trying to get this to work but I have to submit again. I've read the linked docs on variables multiple times. As I understand it, with Puppet you cannot assign top-level variables i.e. starting with $::, these are reserved for facts and other built in Puppet values.

It is correct that facts and certain Puppet-based data are available to to the catalog compiler top-scope variables.  It is incorrect that these are the only sources of such variables.  An ENC may set top-scope variables, or you can set them in site.pp, outside any node, class, or definition body.  Also, you can set variables inside a node block.  I think these are still visible elsewhere as unqualified variables (e.g. ${role}, not ${::role}), but at one point there was a plan to basically make them inaccessible outside the block in which they were declared.

 

So I assign $role = "nameserver" in the role::nameserver class - this works and I get no errors. However no matter what I do hiera doesn't recognise the variable as shown below.

- "%{::environment}/%{::clientcert}"
- "%{::clientcert}"
- "%{::environment}
- "%{role}"
- common

Any ideas what could be causing this?

You are setting ${role::nameserver::role}.  Hiera is performing its lookup in a different context and therefore not resolving the unqualifed 'role' to the same thing.

How best to proceed depends on several things, among them how big your role-specific data are, and how they fit into the overall picture of your data hierarchy.


John