Em sexta-feira, 11 de julho de 2014 11h11min17s UTC-3, jcbollinger escreveu:
>
>
> So, I'm interpreting the hiera data as providing configuration details
> that, if present, apply to every 'myservice', at least as defaults.
> Furthermore, from the data and manifests I judge that 'myproblematicconfig'
> is a distinguished identifier, handled in a manner specific to it.
>
Almost that. I have quite some configurations like that but almost all of
them are applied on a single ERB template. The "problematicconfig", on the
other hand, will manage different files. So AFAICS the iteration need to be
at the Puppet manifest side. create_resources() is the way I have found to
iterate a hash without parser=future.
A different structure for your data might work better
>
Share your thoughts! No problem with some refactor.
, but you can also work with the data structure you already have. In
> particular, create_resources() can often be replaced by an array-titled
> resource declaration with the array drawn from the keys() of your resource
> hash. Combinatorial resource declarations are a bit trickier, but they can
> be done, even without the future parser.
>
Got the idea, nice approach with keys+regsubst, thank you very much.
You may be able to make that cleaner, simpler, or otherwise better by
> applying some of your knowledge of the problem space to the structure of
> the defined types.
>
Digging a bit more into the problem I found another approach: define a
local variable with the $title just before the hiera_hash call, and use
such local variable in the hash declaration. Something like this:
Manifest:
class profile::my::myservice {
$mytitle_hiera = $title
# ENC: $myservices
$hiera_myservice_host = hiera("myservice_host")
# ENC has per-host/service and hiera has per-environment configurations
create_resources(::myservice::host, $myservices, $hiera_myservice_host)
}
Hiera:
myservice_host:
myproblematicconfig:
%{mytitle_hiera}_config1:
data
%{mytitle_hiera}_config2:
data
myotherconfig:
...
It worked like a charm in my configuration. On the other hand Puppet
docs[1] says this is not a good practice. I follow the doc in the sense
that the lookup will be dependent of a manifest configuration. Best
practices, straightforward code and fit the needs are really challenging.
[1] http://docs.puppetlabs.com/hiera/latest/variables.html#best-practices
Joao Morais
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/211dcabf-d379-4bea-a1ab-6a99459d0425%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
