Or you could share ssdata between hiera keys in the environment hiera with 
https://docs.puppet.com/hiera/3.3/variables.html#the-alias-lookup-function


On Wednesday, June 14, 2017 at 10:05:13 PM UTC+2, Christopher Wood wrote:
>
> Thank you, had forgotten about that one, it's a good read. 
>
> I'm a bit leery of adding inheritance to the mix, some people here have 
> enough trouble understanding a hiera_hash(). 
>
> However, I hadn't considered adding module data into the mix. I think I 
> can put enough into the module data to make the profiles much easier to 
> understand. In my case both profiles will indeed share enough to make this 
> worthwhile. 
>
> Thank you both, that is much food for thought. 
>
> On Wed, Jun 14, 2017 at 11:31:12AM -0400, Rob Nelson wrote: 
> >    You may want to look at automatic parameter lookup, inheritance, and 
> data 
> >    in modules. 
> >    [1]
> https://www.devco.net/archives/2016/01/08/native-puppet-4-data-in-modules.php 
> >    has some good examples. Generally, a param class is obviated in a 
> >    component module, but in profiles where a value may be shared across 
> many, 
> >    you could try something like this to be closer to your example 1: 
> > 
> >    class profile::sslparams ( 
> >      Hash $ssldata, 
> >    ) { 
> >      # Nothing actually in the class, we just want the params above ^^ 
> >    } 
> > 
> >    class profile::http ( 
> >      Hash $ssldata = $profile::sslparams::ssldata, 
> >    ) inherits profile::sslparams { 
> >      # use $ssldata wherever you need it 
> >    } 
> > 
> >    You can then set profile::sslparams::ssldata as needed in the 
> module's 
> >    hiera data. 
> > 
> >    Like Matthew Kennedy, though, I'm not certain this is really what you 
> want 
> >    to do. Do both http and smtp always have the same values? Do they 
> actually 
> >    require the data in the exact same format? Can you provide default 
> values 
> >    for each, perhaps through data in modules, and override both 
> >    profile::http::ssldata and profile::smtp::ssldata as needed? Maybe it 
> >    isn't even needed if you are loading component modules like apache 
> and 
> >    postfix, as you could just `include apache` and set 
> `apache::somesslparam: 
> >    value1` and `postfix::differentsslparamname: value2` and not have to 
> embed 
> >    that in your profile classes. 
> >    Rob Nelson 
> >    [2][email protected] <javascript:> 
> >    On Wed, Jun 14, 2017 at 11:05 AM, Christopher Wood 
> >    <[3][email protected] <javascript:>> wrote: 
> > 
> >      I've been pondering this and I'm still tossing it back and forth in 
> my 
> >      head. 
> > 
> >      Example 1: 
> > 
> >      class profile::ssl { 
> >        $ssldata = lookup('profile::ssl::ssldata', Hash) 
> >      } 
> > 
> >      class profile::http { 
> >        include ::profile::ssl 
> >        $ssldata = $::profile::ssl::ssldata  # illustrating the example 
> >      } 
> > 
> >      class profile::smtp { 
> >        include ::profile::ssl 
> >        $ssldata = $::profile::ssl::ssldata  # illustrating the example 
> >      } 
> > 
> >      Example 2: 
> > 
> >      class profile::http { 
> >        $ssldata = lookup('ssldata', Hash) 
> >      } 
> > 
> >      class profile::smtp { 
> >        $ssldata = lookup('ssldata', Hash) 
> >      } 
> > 
> >      Items: 
> > 
> >      In example 1 Every profile would definitely own specified hiera 
> keys 
> >      with no orphans. 
> > 
> >      In example 1 some profiles would end up as "params" profiles if 
> they 
> >      don't have any resources. This is likely fine if it's important 
> that 
> >      every hiera key is owned by a profile. 
> > 
> >      Example 2 means potentially different merge strategies for 
> different 
> >      profiles which could lead to puzzlement. 
> > 
> >      Example 2 means that if the lookup fails somebody has to go digging 
> in 
> >      hiera rather than it being obvious that somebody hasn't included 
> >      profile::ssl. 
> > 
> >      Example 1 means that some profiles end up tightly coupled. On the 
> other 
> >      hand anything that uses ssl is tightly coupled with anything that 
> >      manages ssl anyway. 
> > 
> >      On balance it seems like example 1 is more work up front for the 
> same 
> >      functional result and easier troubleshooting later, which sounds 
> like a 
> >      reasonable tradeoff. I think I will give it a go. (Presuming I'm 
> even 
> >      understanding your point correctly.) 
> > 
> >      On Tue, Jun 13, 2017 at 08:50:51PM +0000, Matthew Kennedy wrote: 
> >      >    As a general rule you shouldn't have multiple profiles pulling 
> the 
> >      same 
> >      >    data from hiera. 
> >      > 
> >      >    Treat profiles like lego blocks that you can compose as 
> needed. 
> >      > 
> >      >    In this case create a ssl_certs profile who's role is to pull 
> in 
> >      hieradata 
> >      >    via standard parameters. This profile has the responsibility 
> to get 
> >      the 
> >      >    certs on the box etc... 
> >      > 
> >      >    Any profiles that need ssl_certs can `include 
> profile::ssl_certs`. 
> >      Note 
> >      >    that if these profiles need to get the parameters of the 
> ssl_certs 
> >      class 
> >      >    they can be accessed via $profile::ssl_certs::parameter_name. 
> >      > 
> >      >    Hope that helps. 
> >      > 
> >      >    On Mon, Jun 12, 2017, 9:57 AM Christopher Wood 
> >      >    <[1][4][email protected] <javascript:>> wrote: 
> >      > 
> >      >      How do you typically organize your data lookups when you 
> want to 
> >      use the 
> >      >      same hiera data across multiple profiles, themselves 
> possibly 
> >      used 
> >      >      across multiple roles? 
> >      > 
> >      >      A cut down example with fake names: 
> >      > 
> >      >      class role::mailserver { 
> >      >        include ::profile::http 
> >      >        include ::profile::smtp 
> >      >      } 
> >      > 
> >      >      class role::webserver { 
> >      >        include ::profile::http 
> >      >      } 
> >      > 
> >      >      class profile::http ($ssldata) { 
> >      >        class { 'apache': 
> >      >          ssldata => $ssldata, 
> >      >        } 
> >      >      } 
> >      > 
> >      >      class profile::smtp ($ssldata) { 
> >      >        class { 'postfix': 
> >      >          ssldata => $ssldata, 
> >      >        } 
> >      >      } 
> >      > 
> >      >      In this example $ssldata would be a hash of 
> >      loopback+cert+key+chain 
> >      >      sets. 
> >      > 
> >      >      It seems like this is the exact case for the lookup() 
> function 
> >      but 
> >      >      perhaps one of you had a better idea. 
> >      > 
> >      >      (Humorously, I am also taking naming suggestions for the set 
> of 
> >      >      cross-profile hiera keys, however risky that is on a 
> >      puppet-related 
> >      >      list.) 
> >      > 
> >      >      -- 
> >      >      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 [2][5][email protected] 
> <javascript:>. 
> >      >      To view this discussion on the web visit 
> >      >      
> >      [3][6]
> https://groups.google.com/d/msgid/puppet-users/20170612165744.GA13854%40iniquitous.heresiarch.ca.
>  
>
> >      >      For more options, visit [4][7]
> https://groups.google.com/d/optout. 
> >      > 
> >      >    -- 
> >      >    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 [5][8][email protected] 
> <javascript:>. 
> >      >    To view this discussion on the web visit 
> >      >    
> >      [6][9]
> https://groups.google.com/d/msgid/puppet-users/CACx1-q3eywAy5Vvv2PDh3wtqNOk-myy8jJY6OV8a-NqJd_JK9g%40mail.gmail.com.
>  
>
> >      >    For more options, visit [7][10]
> https://groups.google.com/d/optout. 
> >      > 
> >      > References 
> >      > 
> >      >    Visible links 
> >      >    1. mailto:[11][email protected] <javascript:> 
> >      >    2. mailto:[12]puppet-users%[email protected] 
> <javascript:> 
> >      >    3. 
> >      [13]
> https://groups.google.com/d/msgid/puppet-users/20170612165744.GA13854%40iniquitous.heresiarch.ca
>  
> >      >    4. [14]https://groups.google.com/d/optout 
> >      >    5. mailto:[15][email protected] 
> <javascript:> 
> >      >    6. 
> >      [16]
> https://groups.google.com/d/msgid/puppet-users/CACx1-q3eywAy5Vvv2PDh3wtqNOk-myy8jJY6OV8a-NqJd_JK9g%40mail.gmail.com?utm_medium=email&utm_source=footer
>  
> >      >    7. [17]https://groups.google.com/d/optout 
> >      -- 
> >      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 [18][email protected] <javascript:>. 
> >      To view this discussion on the web visit 
> >      [19]
> https://groups.google.com/d/msgid/puppet-users/20170614150552.GA12362%40iniquitous.heresiarch.ca.
>  
>
> >      For more options, visit [20]https://groups.google.com/d/optout. 
> > 
> >    -- 
> >    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 [21][email protected] <javascript:>. 
> >    To view this discussion on the web visit 
> >    [22]
> https://groups.google.com/d/msgid/puppet-users/CAC76iT8V%2B_8p4qJRnhuVhV9%2BiS-PD7J%3D%2B82q5MUcNwPwD84FwQ%40mail.gmail.com.
>  
>
> >    For more options, visit [23]https://groups.google.com/d/optout. 
> > 
> > References 
> > 
> >    Visible links 
> >    1. 
> https://www.devco.net/archives/2016/01/08/native-puppet-4-data-in-modules.php 
> >    2. mailto:[email protected] <javascript:> 
> >    3. mailto:[email protected] <javascript:> 
> >    4. mailto:[email protected] <javascript:> 
> >    5. mailto:puppet-users%[email protected] <javascript:> 
> >    6. 
> https://groups.google.com/d/msgid/puppet-users/20170612165744.GA13854%40iniquitous.heresiarch.ca
>  
> >    7. https://groups.google.com/d/optout 
> >    8. mailto:puppet-users%[email protected] <javascript:> 
> >    9. 
> https://groups.google.com/d/msgid/puppet-users/CACx1-q3eywAy5Vvv2PDh3wtqNOk-myy8jJY6OV8a-NqJd_JK9g%40mail.gmail.com
>  
> >   10. https://groups.google.com/d/optout 
> >   11. mailto:[email protected] <javascript:> 
> >   12. mailto:puppet-users%[email protected] <javascript:> 
> >   13. 
> https://groups.google.com/d/msgid/puppet-users/20170612165744.GA13854%40iniquitous.heresiarch.ca
>  
> >   14. https://groups.google.com/d/optout 
> >   15. mailto:puppet-users%[email protected] <javascript:> 
> >   16. 
> https://groups.google.com/d/msgid/puppet-users/CACx1-q3eywAy5Vvv2PDh3wtqNOk-myy8jJY6OV8a-NqJd_JK9g%40mail.gmail.com?utm_medium=email&utm_source=footer
>  
> >   17. https://groups.google.com/d/optout 
> >   18. mailto:puppet-users%[email protected] <javascript:> 
> >   19. 
> https://groups.google.com/d/msgid/puppet-users/20170614150552.GA12362%40iniquitous.heresiarch.ca
>  
> >   20. https://groups.google.com/d/optout 
> >   21. mailto:[email protected] <javascript:> 
> >   22. 
> https://groups.google.com/d/msgid/puppet-users/CAC76iT8V%2B_8p4qJRnhuVhV9%2BiS-PD7J%3D%2B82q5MUcNwPwD84FwQ%40mail.gmail.com?utm_medium=email&utm_source=footer
>  
> >   23. https://groups.google.com/d/optout 
>

-- 
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/86b9bf57-e6de-44d3-9143-cf5ef9336c20%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to