Hi John, first of all, thanks for your answer.
2018-05-18 14:15 GMT+02:00 jcbollinger <[email protected]>: > > > >> >> "%{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 [email protected]. 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.
