Changing parameters for default/global classes inside a role

[David Bell]

Hello,

Assume an open source Puppet deployment using the roles and profiles paradigm and Heira (https://puppet.com/presentations/designing-puppet-rolesprofiles-pattern)

Lets say I have a role module called 'role_applicationX' which includes two profile modules - "profile_oracle_server" and "profile_tomcat".

Now also assume that all my systems, via the external node classifier, loads a series of base profile modules, such as "tuned" (a Red Hat tool for managing kernel settings). In this list of base profile modules is "profile_tuned".

The profile_tuned class defaults to a tuned system profile of 'virtual' if it finds that the system is virtual based on Facts.

What I want to be able to do is inside the "profile_oracle_server" in some way signal or change "profile_tuned" to use the oracle tuned profile. You can't redefine classes using 'resource-like' syntax, so I can't just change parameters to "profile_tuned". Variables are actually constants, so a profile can't change an existing variable.

Heira doesn't solve this problem, although I'm told that it should, because including profile_oracle_server cannot have any bearing on Heira. Heira is great at letting you change the functionality of classes/modules per-node, but I cannot find a way for 'role' modules to change what a profile module does, without every role having to define all of my base profiles. I'm told that an ENC should only ever set a 'role' for a node, and nothing else, and yet it seems pretty clear to me I also have to store configuration for a role in the node's heira configuration, so I have to change things in multiple places.

What I'd like to do is assign a role to a node and that should alter the base configuration as needed.

The only other option I can think of is a horrible "if not defined define the base profile module" hack where base profiles are only declared via resource-like syntax if a role doesn't define them (i.e. with specific parameters). I'm pretty sure Heira was created to avoid this, and yet it seems the only in-puppet-code option I can think of. 

Any help and advice would be much appreciated.

Cheers,

David Bell

University of Southampton

[Gavin Williams]

David

If you can expose the role as a top-level fact, then you can use that to drive the hiera hierarchy. You can then override the required class params in a role specific yaml file.

HTH
Gav

[David Bell]

Many thanks for your reply Gavin. I have basically gone down this route in my thinking too, except rather than use a fact, I will set up our ENC (a custom ENC we've written) to set a global variable 'role' which can then be used to drive the hiera hierarchy. 

A fact would mean we would have to set the role on the client, or worse, set it via Puppet and then read it on a second run or via puppet stages. That sounds...horrible.

It is a real shame that the ENC functionality in Puppet and Hiera are so disconnected, it would be fantastic if you could set Hiera variables through the ENC. Oh well.

Cheers,

David

[Rob Nelson]

Can you share some of your code? This is somewhat complicated to follow, but probably simpler to view the code. 

However, I believe that what you want is to add a parameter to the class that includes profile_tuned, perhaps called $is_oracle. If the parameter is false, include profile_tuned, if true, include profile_tuned_for_oracle. Or, move that inside the class profile_tuned. You can then set 'profile_whatever::is_oracle: true' via hiera and everything will flow properly. 

How you do that in your hierarchy is up to you but a fact-based tier is a good idea. Keep in mind that facts are distributed and reported to the master BEFORE catalog compilation, so they shouldn't need a second run to take effect - unless their value is dependent upon software that puppet would install on its first run.

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/329bc309-4780-4a6c-9bd6-15b9f8b0827c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Rob Nelson
rnel...@gmail.com