How do i set the effective role if there is a subrole

50 views
Skip to first unread message

Ivan Arjune

unread,
Sep 12, 2016, 2:01:38 AM9/12/16
to Puppet Users

If my server has a subrole, how do i set the effective role so that the correct class gets compiled?  Please read through my setup before answering, maybe what i want to do is incorrect for this setup.


The way I setup roles and profiles is like this:


Nodes are given a role and a subrole by custom facts.

role: mail
subrole
: relay



I use hiera_include('classes') in my site.pp. 


And each role has a file in hieradata.  The hiera.yaml looks like this. 

:hierarchy:
 
- "nodes/%{::trusted.certname}"
 
- "roles/%{::role}"
 
- common


The profiles for the role are defined in hieradata/roles/mail.yaml which looks like this:

---
classes
:
 
- profile::mail


The mail profile will have the different subroles classes in it.  In this example subroles internal or relay are possible
class profile::mail::internal {
   
class { 'postfix':
      relayhost
=> '192.168.0.1',
   
}
}

class profile::mail::relay {
  include amavisd
  include something_else
 
class { 'postfix':
      relayhost
=> 'external.mail.com',
      mynetworks
=> '192.168.0.0/16',
   
}
}


I'm stumped at this point, where the subroles are defined.  How do i set the effective role to be mail::relay? 

I have two ideas:
Put if statements around each subrole in the profile manifest.
or
Since you can't do logic in yaml, do the ENC stuff another way.

humm, is there a way to do this in hieradata/roles/mail.yaml?

This is a typical setup, I think.  I just haven't found a working example to this.


Ivan Arjune

unread,
Sep 21, 2016, 3:22:13 PM9/21/16
to Puppet Users
Are subroles implemented as a conditional statement within the profile manifest?

Rob Nelson

unread,
Sep 21, 2016, 7:42:29 PM9/21/16
to puppet...@googlegroups.com
Ivan,

In discussing roles, I always encourage reviewing http://www.craigdunn.org/2012/05/239/, the original guideline for the roles and profiles pattern. It posits that the role, like the profile, is just another class inside the 'role' module - role::www, role::mail, etc - that is composed of profile classes - profile::apache, profile::webapp, etc. Lots of examples in the document. The "rules", which are more like guidelines, are near the bottom (emphasis mine):
  • A node includes one role, and one only.
  • A role includes one or more profiles to define the type of server
  • A profile includes and manages modules to define a logical technical stack
  • Modules manage resources
  • Modules should only be responsible for managing aspects of the component they are written for
Another guideline that has cropped up since 2012 is: If a node requires two roles, it's time to create a new role that fits that need. So, subroles would actually be new roles - role::webapp1 and role::webapp2 rather than assigning role::web and role::app1 to a single node, for example. This ensures that roles do not become coupled in accidental manners, where someone wants to tweak a setting for webapp1 that happens to be in role::web, causing side effects to webapp2.

Going back to your previous email, you also described role::mail where some nodes are relays. You may need a second role for this, but it is also possible that one of the profiles (maybe profile::mailapp) or the component module it calls (postfix or sendmail) accept parameters that indicate whether a node is a relay or not. In that case, you could use hiera to pass different values to those parameters for different nodes. I wrote a bit on the merging of Roles and Profiles with Hiera data at https://rnelson0.com/2014/07/14/intro-to-roles-and-profiles-with-puppet-and-hiera/ that may help.

On Wed, Sep 21, 2016 at 3:22 PM, Ivan Arjune <iar...@gmail.com> wrote:
Are subroles implemented as a conditional statement within the profile manifest?

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/886ef534-a8de-454c-93dd-d8fae9c2dcc1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply all
Reply to author
Forward
0 new messages