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]christopher_w...@pobox.com> 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]puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
>
> [3]https://groups.google.com/d/msgid/puppet-users/20170612165744.GA13854%40iniquitous.heresiarch.ca.
> For more options, visit [4]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]puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
>
> [6]https://groups.google.com/d/msgid/puppet-users/CACx1-q3eywAy5Vvv2PDh3wtqNOk-myy8jJY6OV8a-NqJd_JK9g%40mail.gmail.com.
> For more options, visit [7]https://groups.google.com/d/optout.
>
> References
>
> Visible links
> 1. mailto:christopher_w...@pobox.com
> 2. mailto:puppet-users%2bunsubscr...@googlegroups.com
> 3.
> https://groups.google.com/d/msgid/puppet-users/20170612165744.GA13854%40iniquitous.heresiarch.ca
> 4. https://groups.google.com/d/optout
> 5. mailto:puppet-users+unsubscr...@googlegroups.com
> 6.
> https://groups.google.com/d/msgid/puppet-users/CACx1-q3eywAy5Vvv2PDh3wtqNOk-myy8jJY6OV8a-NqJd_JK9g%40mail.gmail.com?utm_medium=email&utm_source=footer
> 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 puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/20170614150552.GA12362%40iniquitous.heresiarch.ca.
For more options, visit https://groups.google.com/d/optout.
