On Tuesday, June 12, 2012 1:48:09 PM UTC-5, Wolf Noble wrote:
>
> So… I'm coming across a situation where I foresee myself having a
> collection of related k/v pairs in hiera. I want to create a thing… lets
> say a yumrepo for example's sake, but this same idea translates to a
> vhost, a web app configuration , a virtual domain, etc.
>
> lets assume a hierarchy of:
>
> - %{region}/%{dc}/%{env}/%{function}/%{fqdn}
> - %{region}/%{dc}/%{env}/%{function}/common
> - %{region}/%{dc}/%{env}/common
> - %{region}/%{dc}/common
> - %{region}/common
>
> in the us-east region common yaml file, should I create the following two
> repos values:
>
> repo_descr: eastcoast-pub
> repo_baseurl: http://myfoo.com/eastcoastgoodtimes
> repo_gpgkey: http://myfoo.com/eastcoastgoodtimes/key
> repo_gpgcheck: 1
> repo_enabled: 1
> repo_enablegroups: 0
>
> repo_descr: eastcoast-internal
> repo_baseurl: http://myfoo.com/eastcoast
> repo_gpgkey: http://myfoo.com/eastcoast/key
> repo_gpgcheck: 1
> repo_enabled: 1
> repo_enablegroups: 0
>
>
> in the foo DC common file I have a repo for that datacenter:
>
> repo_descr: foo
> repo_baseurl: http://myfoo.com/goodtimes
> repo_gpgkey: http://myfoo.com/goodtimes/key
> repo_gpgcheck: 1
> repo_enabled: 1
> repo_enablegroups: 0
>
>
>
> in the 'qa' env common yaml file
>
> repo_descr: fooqarepo
> repo_baseurl: http://myfoo.com/qa_crispybacon/goodtimes
> repo_gpgkey: http://myfoo.com/qa_crispybacon/goodtimes/key
> repo_gpgcheck: 1
> repo_enabled: 1
> repo_enablegroups: 0
>
>
>
> in the webservers function common yaml file, I have another repo:
>
> repo_descr: webservers
> repo_baseurl: http://myfoo.com/bacon/goodtimes
> repo_gpgkey: http://myfoo.com/bacon/goodtimes/key
> repo_gpgcheck: 1
> repo_enabled: 1
> repo_enablegroups: 0
>
>
>
>
>
>
> so I want all the qa web servers in the foo DC in the east coast to have
> all five of those repo files defined.. except for web02, of course, because
> he's special… looking at it this way makes my head hurt. I don't see a good
> way to actualize these repos onto a node, or exclude them from a unique
> snowflake if necessary, which sort-of defeats the purpose of hiera
> altogether.
>
> Do I not create them as separate keys, but as a single 'repo' array, and
> in my manifest use a template to iterate through the array and associate
> the values contained within the array with values needed for the addition
> of a repo?
>
> What have people found works "best"?
>
For complex data you need to put some structure in your YAML and process it
accordingly in your manifests. In particular, in this case it would be to
your advantage to use hiera's (and YAML's) support for arrays and / or
hashes as values. For example:
in us-east/common.yaml:
======
region_repos:
eastcoast_pub_repo: {
descr: eastcoast-pub,
baseurl: http://myfoo.com/eastcoastgoodtimes,
gpgkey: http://myfoo.com/eastcoastgoodtimes/key,
gpgcheck: 1,
enabled: 1,
enablegroups: 0
},
eastcoast_internal_repo: {
descr: eastcoast-internal,
baseurl: http://myfoo.com/eastcoast,
gpgkey: http://myfoo.com/eastcoast/key,
gpgcheck: 1,
enabled: 1,
enablegroups: 0
}
======
That's a hash of hashes, associated with the key "region_repos". You could
use that in your manifests like so:
mymodule::repos {
create_resources('yumrepo', hiera('region_repos'))
# perhaps also create_resources('yumrepo', hiera('dc_repos')), etc.
}
If that looks simple, that's because I tailored the YAML data structure to
the expectations of the create_resources() function.
It's also because the structure assumes that you will explicitly load the
data for each hierarchy level you want, instead of, for example, using
hiera_array() or hiera_hash() to assemble an even more complex aggregate
data structure from various levels of your hierarchy. I think that's
reasonable for your use case, especially given that you anticipate certain
machines will need exceptions. You're still getting indirection out of it
because hiera is choosing the appropriate region-, dc-, and
environment-specific data files.
There are many other ways to do it, but that one has the advantage of being
simple (relatively speaking) and fairly easy to understand.
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/Rug-iffTkLkJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
