Hi John,
first of all, thanks for your answer.
2018-05-18 14:15 GMT+02:00 jcbollinger <john.bollin...@stjude.org>:
>
>
>
>>
>> "%{environment}/hieradb/profile/profileA.yaml"
>> "%{environment}/hieradb/profile/profileB.yaml"
>> "%{environment}/hieradb/profile/profileC.yaml"
>>
>> Based on my tests (yup, I tried this) if hiera finds the value in, let's
>> say, profileB.yaml it stops scanning this level and profileC.yaml is not
>> evaluated.
>>
>
>
> I find that doubtful. Given the hierarchy definition you specified
> earlier, I expect Hiera to read at most one of those files whether it finds
> the value there or not.
>
Ah, ok, so it only reads one file. Then the conclusions from my tests were
wrong (and probbaly because of werid coincidence).
>
>
>> In any case, even if hiera continues scanning all files in the same
>> lelve, this approach will create a conflic in hiera itself whenever it
>> finds the same variable defined in 2 profiles. ¿Which one should I choose?
>>
>
>
> For data at different hierarchy levels, this is where Hiera's various
> merge behaviors come into play. The default is that the first value found
> is used, but you can instead collect all values into an array, or, for
> hashes, merge the various hashes in one of two ways.
>
> But note well that if you have different profiles trying to specify values
> for the same data then that's a serious conflict that you need to work out
> -- a data design problem, not inherently an Hiera problem.
>
Sure, I never said it was a hiera issue. Hiera itself, in the case of
reading the same data from 2 differnet profiles, will never be able to
decide which data to choose. Totally clear.
>
>
>> So, the (obvious) solution is to move any profile customization to the
>> role level, the same I've been doing till now.
>> But I was wondering if some part of my approach could be possible
>> (without having to decalre all the possible profiles in my hiera tree) or
>> if someone was somehow using the "profile" in the hiera tree (and how)?.
>>
>
>
> You can parameterize your profile classes, and then rely on standard data
> binding to obtain the values from Hiera. The data for different profiles
> are then distinguished by different keys, and they can appear at any
> Hierarchy level.
>
That's what I was doing in my previous hiera tree. The issue now was that I
wanted to use the "profile" custom_fact as a key to hiera.
> For data that you want to share among profiles without duplication, you
> can define well-known keys and explicitly call the lookup() function in
> each profile to retrieve the (same) associated data. Or you can define a
> separate class to host the variables, set their values via automated data
> binding, and have all the profiles that want access obtain it via that one
> class. Either way, again, the data can then appear at any hierarchy level.
>
> If this is about class parameters for the classes your profiles use, then
> you could perhaps risk having the profiles declare those with resource-like
> class declarations (instead of include-like ones), whereby you can bind
> data to the classes' parameters via DSL code.
>
Let me tell you what I wanted to do: I wanted to build the "classes" hash
based on different profiles. So, insetad of writing classes for each
profile and then "collect" them in the role in hiera:
roleA.yaml
classes:
- profileA
- profileB
and then declaring the classes:
class profileA {
include apache
}
class profleB {
include mysl
}
I wanted to do:
profileA.yaml
classes:
- apache
profileB.yaml
classes:
- mysql
roleA.yaml
custom_facts:
- profileA
- profileB
then "merge" the classes hash so it pick classes for all the profiles a
node belongs to....
The main reason is to not having to write classes for each profile and do
as much as I can in hiera.
I'm not sure if my idea makes sense to you, or if I explained it properly.
But with teh potential of hiera3 + Puppetfile I wanted to avoid writing
puppet code as much as possible.
>
> John
>
>
Arnau
--
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/CAM69jx8NUR8QbPZnYuxcFbmw0ri6aG9Bjv%2BvUH4zX0jCt__A%3Dw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
