Hi Larry,
I'm curious to your opinion on point # 3, are you talking about OS packages
or your organizations app version? If the latter, I was thinking of using
hiera, maybe with a backend other than yaml such as redis, to store the
version of the app, that way like you said it could be used in deploy
pipeline. Why wouldn't you want to do this?
In addition to what everyone else has said, one of the bigger win's of
using hiera, is the flexibility it offers you with overriding variables.
With the below hierarchy you can override based off an individual server,
environment or datacenter. This could be powerful if you wanted to test
some new JVM settings on just one server in production or an entire
datacenter. You can use any facter fact you want to define your hierarchy.
:hierarchy:
- %{fqdn}
- env/%{env}/common
- datacenter/%{datacenter}
- common
Drew
On Sunday, May 5, 2013 2:04:19 PM UTC-4, Larry Fast wrote:
>
> Hi Josh,
> Here's what we found. I would love to hear about other approaches because
> we're still debating and building out our service.
>
> 1. Yes it's a great way to escape from parameterized classes. If you ever
> needed to 'include' a class in two places, parameterized classes makes this
> difficult or impossible.
> 2. I don't recommend using automatic hiera lookup. There are some subtle
> gotchas in it especially when using hashes in hiera. In my office our
> recommended practice is as almost as you wrote it, class bar ($foo =
> hiera('bar::foo')) { ... }. Hiera automatic lookup is a good way to allow
> an easier transition from parameterized classes so it may still be a good
> choice for you. As Ashley points out, read the latest docs!
> 3. If you explicitly use the hiera() call, you'll get nice "variable not
> found" messages when you make a mistake. Clear error messages are rare in
> puppet so don't underestimate their value.
> 4. Don't over complicate your hiera tree. It's not the place for
> everything. Pick your largest collection of system-to-system variation and
> put that in hiera.
>
> In our office we identified three variations that we *wanted* to put in
> hiera:
> 1. Variation between servers *within* an instance of our service
> 2. Variation between similar servers across different instances of our
> service (eg. Identity of the zookeeper in production, staging & QA)
> 3. Version differences between instances of our service. IE. use hiera to
> manage the pipeline of releases.
>
> What we *actually* put into hiera was only #2. When #1 started creeping
> into hiera things got very messy. #1 is better handled by managing server
> Roles. #3 should never go into Hiera - but I'm still arguing this point
> with my co-workers.
>
> Caveate Emptor: We're still hemming and hawwing about all this.
> Cheers, Larry Fast
>
>
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
