roles, profiles, and hiera

[Chad Huneycutt]

I have been following the various blog posts about the roles and
profiles pattern for classifying hosts, and I like it. It doesn't
provide a perfect fit for our infrastructure, but it is much better
than the ad-hoc classification we do now. I have a couple of
questions for those that use it, though:

1. Where are you putting your role classes and profile classes? A
role module and a profile module makes sense to me, but it seems like
something more tightly integrated with the Puppet DSL might be nice?

2. Assuming you have roles and profiles in modules, at what point do
you specify the parameters to your modules? I am particularly
interested in the answer to this question with regards to hiera. I
find that I want to add roles and profiles to the hiera hierarchy, and
I cannot come up with a way to do it.

I think if hiera supported lookup by the class containing the hiera
call, I could achieve what I want. For instance:

class profiles::oneofmyprofiles {
include myparameterizedclass
}

I would like to have a hiera.yaml like so:

---
:backends:
- yaml
:hierarchy:
- nodes/%{::hostname}
- profiles/%{class_name}
- common
:yaml:
:datadir: /etc/puppet/environments/%{environment}/data


Am I just completely off-base?

--
Chad M. Huneycutt

[Brian Lalor]

Will this help? http://docs.puppetlabs.com/puppet/3/reference/lang_variables.html#parser-set-variables

--

Brian Lalor

bla...@bravo5.org

--
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 post to this group, send email to puppet...@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Vaidas Jablonskis]

Hi there,

I was going to ask exact same questions too.

I am also interested in how people solve these problems.

[jcbollinger]

On Wednesday, February 13, 2013 5:17:40 PM UTC-6, Chad Huneycutt wrote:

I would like to have a hiera.yaml like so:

---
:backends:
  - yaml
:hierarchy:
  - nodes/%{::hostname}
  - profiles/%{class_name}
  - common
:yaml:
  :datadir: /etc/puppet/environments/%{environment}/data


Am I just completely off-base?

No, but it's spelled %{calling_class}.  There is also %{calling_module}.  Do be aware of http://projects.puppetlabs.com/issues/14985, however.


John
 

[Chad Huneycutt]

It is my understanding that the calling_* variables are only available
to the puppet backend. At least they do not work for me.
%{module_name}, on the other hand, works as I expect it to with the
yaml backend.

> --
> 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 post to this group, send email to puppet...@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
Chad M. Huneycutt

[Chad Huneycutt]

Unfortunately not. I am already using %{module_name}, and it works
fine. But for what I am suggesting to work, I need to know the exact
class where the hiera call is.

- Chad

--
Chad M. Huneycutt

[jcbollinger]

On Thursday, February 14, 2013 12:08:17 PM UTC-6, Chad Huneycutt wrote:

It is my understanding that the calling_* variables are only available
to the puppet backend.  At least they do not work for me.
%{module_name}, on the other hand, works as I expect it to with the
yaml backend.

I can't speak to whether or why these currently work for you, but they are certainly not targeted specifically at the Puppet back end.  They are mostly intended for use in your hiera configuration file (hiera.yaml), which is independent of any particular back end (since it's where you define which one(s) to use).  It's precisely the use case you described.

With that said, it looks like at least one other bug has been filed against this functionality in Puppet 3, so perhaps you're running up against that.  In any case, I still say no, you're not off-base: what you're asking for is supposed to already work.


John

[Chad Huneycutt]

Thanks, John. I think you are right that puppet should support it,
but I am pretty sure it does not. I chatted with RI, and it seems
that the classname is not "exposed", so when the puppet backend does
the lookup, it figures out the classname and sets the 'calling_class'
variable before it interprets the hierarchy. I am going to try to
hack the same thing into the yaml backend, as well as file a bug (or
+1 one) about it.

- Chad

[jcbollinger]

On Thursday, February 14, 2013 1:45:36 PM UTC-6, Chad Huneycutt wrote:

Thanks, John.  I think you are right that puppet should support it,
but I am pretty sure it does not.   I chatted with RI, and it seems
that the classname is not "exposed", so when the puppet backend does
the lookup, it figures out the classname and sets the 'calling_class'
variable before it interprets the hierarchy.  I am going to try to
hack the same thing into the yaml backend, as well as file a bug (or
+1 one) about it.

Yes, R.I. was explaining the current state of the code, as is also summarized in the PL bug tracker.  In addition to issue 14985, which we discussed above, there is http://projects.puppetlabs.com/issues/16730, which speaks directly to how %{calling_class} and %{calling_module} could be used in hiera.yaml in Puppet 2.7, whereas Puppet 3 apparently regressed on that.  That issue has been marked as a duplicate of 14985, however; I mention it to give you confidence about which issue to watch / vote up (14985).  Also to confirm that PL not only agrees that there's an issue, but has a solution in flight.


John

[Steve Roberts]

 
This is very good to hear.  A few of weeks ago I was told about the calling_* vars in #puppet IRC when I was looking to solve basically the same sort of task.

then  when I tried to use them this past weekend and it didn't work, I asked in #puppet again if there was an issue, and folks acted like I was crazy for thinking calling_{class,module} were supposed to work.

Looking forward to having the issue resolved.

 

[JuanBrein]

Today looking for a solution to this I came up with a nice solution. I know this thread is old but I'm posting it just in case is useful for somebody:

on hiera.yaml:

:hierarchy:
  - 'host/%{::domain}/%{::hostname}'
  - 'domain/%{::domain}'
  - 'role/%{system_role}'
  - 'common'

on site.pp

node default {

  $system_role = get_system_role()

}

and get_system_role is a custom function:

require 'yaml'

module Puppet::Parser::Functions

  newfunction(:get_system_role, :type => :rvalue) do |args|

    hostname = lookupvar('fqdn')

    enc = %x[/etc/puppet/node.rb #{hostname}]

    yaml = YAML::load enc

    system_role = yaml['classes'].keys.first.scan(/::([a-z]*)/).flatten[0]


  end

end

This is asuming you use an ENC to assign classes like foreman / cobbler or pe

Cheers

Juan

[Atom Powers]

This seems overly complicated. If you use an ENC then you can put arbitrary facts into the data returned by the ENC as "parameters". Since the ENC is processed before Hiera you can set your hierarchy based on those parameters and you can put anything else you want in there too.

My ENC is similar to your ruby script, except that it basically just returns the data in 

heiradata/hosts/%{hostname}.yaml where I have something like:

---

environment: 'production'

parameters:

  role: 'web-server'

  department: 'marketing'

  manager: 'that-guy'

And in your hiera.yaml

---

:hierarchy:

 - roles/%{role}

 - departments/%{department}

 - managers/%{manager}

--

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/be999593-f554-4e30-aab0-d75392a593a0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Perfection is just a word I use occasionally with mustard.
--Atom Powers--