You may want to look at automatic parameter lookup, inheritance, and data
in modules.
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
rnels...@gmail.com
On Wed, Jun 14, 2017 at 11:05 AM, Christopher Wood <
christopher_w...@pobox.com> 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]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.
>
--
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/CAC76iT8V%2B_8p4qJRnhuVhV9%2BiS-PD7J%3D%2B82q5MUcNwPwD84FwQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
