Re: [Puppet Users] same hiera data across multiple profiles
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]rnels...@gmail.com
>On Wed, Jun 14, 2017 at 11:05 AM, Christopher Wood
><[3]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 +, 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]christopher_w...@pobox.com> wrote:
> >
> > How do you typically organize your data lookups when you want to
> use the
> > same hiera data across
Re: [Puppet Users] same hiera data across multiple profiles
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 +, 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
Re: [Puppet Users] same hiera data across multiple profiles
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 +, 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_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
Re: [Puppet Users] Officiel master puppet and source Puppet agent
Probably not 100% what you're looking for, but you might get some use out of the Debian puppet sources. They have packages for various ARM architectures too. https://packages.debian.org/search?keywords=puppet On Wed, Jun 14, 2017 at 06:03:17AM -0700, Fairouz el ouazi wrote: >HI , > Is there any possibility to have Entreprise Puppet Master . and >downloading puppet agent from sources in order to make it works on ARM >devices ? > >Thanks >Fairouz > >-- >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 [1]puppet-users+unsubscr...@googlegroups.com. >To view this discussion on the web visit > > [2]https://groups.google.com/d/msgid/puppet-users/4abd639e-e9d4-4509-9918-6a6a11ed476d%40googlegroups.com. >For more options, visit [3]https://groups.google.com/d/optout. > > References > >Visible links >1. mailto:puppet-users+unsubscr...@googlegroups.com >2. > https://groups.google.com/d/msgid/puppet-users/4abd639e-e9d4-4509-9918-6a6a11ed476d%40googlegroups.com?utm_medium=email_source=footer >3. 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/20170614133919.GA11905%40iniquitous.heresiarch.ca. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Officiel master puppet and source Puppet agent
HI , Is there any possibility to have Entreprise Puppet Master . and downloading puppet agent from sources in order to make it works on ARM devices ? Thanks Fairouz -- 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/4abd639e-e9d4-4509-9918-6a6a11ed476d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Does create_resources support virtual resources?
On Saturday, March 31, 2012 at 6:04:28 AM UTC+11, Gary Larizza wrote: > > Create_resources doesn't support virtual users, but Hiera DOES support > hash-merging, so it could find all users in all hierarchies with hiera_hash > and then declare them at once. Presumably at some point this feature was added; create_resources does in fact now support virtual and exported resources: https://docs.puppet.com/puppet/latest/function.html#createresources It's also in the at least latest version of Puppet 3. -- 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/5dc5a77b-a3c7-41a7-ab39-126973696c41%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
