hiera suggestion

77 views
Skip to first unread message

Andrey Kozichev

unread,
Jan 21, 2014, 6:28:25 AM1/21/14
to puppet...@googlegroups.com
Hi community, I need a suggestion.
Some of my modules like nagios or nfs shares are having a lot of static data which needs to be defined in the bottom of hierarchy. 
It makes my file generic.yaml quite massive and not that readable.
What are the options do I have to separate this into more structured tree?
What are the best practices?

The first thing comes to mind is to add few more files in to hiera:


...
  - %{::site}

  - generic

  - nagios_services

  - nfs_shares

etc..

Or is it better to avoid this?

Any thoughts? 

--
Andrey

Pete Brown

unread,
Jan 21, 2014, 5:39:53 PM1/21/14
to puppet-users
My question would be what are you doing with nagios that need so much
static data?
My monitoring module uses facts and one or two static vars.

I would suggest putting defaults in your modules so you don't need to
set so many variables.
Basing those defaults of custom facts would help reduce your need to
set vars in hiera.
> --
> 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/CACzr%3DFfQtU9Q5rjQT72Qur%2BzTqEcOHbG1x%2Bt5EnL7Bj1Hbv6Bg%40mail.gmail.com.
> For more options, visit https://groups.google.com/groups/opt_out.

Andrey Kozichev

unread,
Jan 22, 2014, 2:20:13 AM1/22/14
to puppet...@googlegroups.com

Those are mostly definitions of custom checks to export + templates which group those checks by server types

Jose Luis Ledesma

unread,
Jan 22, 2014, 2:39:48 AM1/22/14
to puppet...@googlegroups.com
Copied from another thread:

:hierarchy:
...
- "%{environment}/classes/%{calling_class}

Perhaps it is easier that way.

Regards

Andrey Kozichev

unread,
Jan 22, 2014, 7:10:02 AM1/22/14
to puppet...@googlegroups.com

Yes, I was thinking something like that.

Is there a %{module} variable ?

--
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.

Felix Frank

unread,
Feb 7, 2014, 3:49:30 AM2/7/14
to puppet...@googlegroups.com
Hi,

bumping an older thread, because that just caught my eye.

On 01/21/2014 11:39 PM, Pete Brown wrote:
> I would suggest putting defaults in your modules so you don't need to
> set so many variables.

I started actively avoiding that, actually, for the reason that hiera
values may see use in different parts of a module, e.g. in the manifests
and one or more templates. Adding a default to each of those hiera()
calls adds potential for inconsistencies, especially when a default
changes at one point.

Therefor, the hiera values that are expected by modules get mandatory
defaults from the bottom of my hierarchy.

Any feedback is welcome though.

Thanks,
Felix
Reply all
Reply to author
Forward
0 new messages