FAQ
Hi all,

We've recently started exploring the role / profile / component module
described by Craig Dunn in his blog here:
http://www.craigdunn.org/2012/05/239/ and discussed on the list the other
day. As I was implementing this for
a profile using the apache module, I realized that I could make another
refinement to our approach by using
create_resources('class','<module name>') to pull our hiera data into the
apache class and override any defaults needed.
It looks good to me but there are some concerns that it will come back and
bite us in ways we don't expect
later on, when updating to Puppet 3.0. The benefit right away is that it
saves us from having to even touch
puppet forge modules to 'hierafy' them, and it is much less code to write
and maintain, simply by structuring
class param hiera data as a hash of key-value pairs instead of flat
key-value pairs in the yaml. Any guidance
or warnings or comments in general would be most helpful to us in deciding
how to go forward.

We're using Puppet Enterprise 2.7 and plan to eventually update to 3.0
later on down the line.

Here's an example of our new idea (I'm using the refactored apache from the
github refactor branch):

apache_params:
apache:
default_mods : true
default_vhost : false
default_ssl_vhost : false
service_enable : true
serveradmin : 'root@localhost'
sendfile : false
error_pages : false

apache_vhosts :
testvhost1.com : {
ip : '10.0.0.9',
port : '81',
docroot : '/tmp/testvhost1.com',
ssl : True
}
testvhost2.com : {
ip : '10.0.0.9',
port : 82,
docroot : '/tmp/testvhost2.com'
}


The code to pull from hiera (for Puppet 2.7) can then be very simple and
decoupled from the module code:
class profile::apache_stack {
$apache_params = hiera('apache_params', false)
if $apache_params {
create_resources('class', $apache_params)
}

$vhosts = hiera('apache_vhosts', false)
if $vhosts {
create_resources( 'apache::vhost', $vhosts )
}
}

That is all of the hiera data and all of the program code, aside from the
unmodified apache module.

The apache module code is completely untouched by any of this. Default
values are set in the params.pp
by the package maintainers and if hiera does not have an override in
$apache_params{'apache'} the default
comes from the module.


Here is the other way that we have been doing things, where hiera has all
defaults in yaml explicitly
sets each variable:

apache_ssl_enabled: True
apache_vhost_default_conf: 'apache/vhost-default.conf.erb'
apache_priority: '25'
apache_servername: ''
apache_serveraliasess: ''
apache_auth: false
apache_redirect_ssl: false
.
.
.
and about 35 more lines like this.

class apache::params {
if $hiera_enabled {

$ssl = hiera(apache_ssl_enabled, True)
$template = hiera(apache_vhost_default_conf,
'apache/vhost-default.conf.erb')
$priority = hiera(apache_priority, '25')
$servername = hiera(apache_servername, '')
$serveraliases = hiera(apache_serveraliasess, '')
$auth = hiera(apache_auth, false)
$redirect_ssl = hiera(apache_redirect_ssl, false)
.
.
.
and about 35 more lines like this, followed by more code to set defaults if
hiera is not enabled.

Thoughts?

Thanks very much for reading!

- Eric

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/UHAN4L56QQ8J.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

Search Discussions

  • Jcbollinger at Jan 14, 2013 at 3:25 pm

    On Friday, January 11, 2013 2:14:46 PM UTC-6, Eric Sakowski wrote:
    Hi all,

    We've recently started exploring the role / profile / component module
    described by Craig Dunn in his blog here:
    http://www.craigdunn.org/2012/05/239/ and discussed on the list the other
    day. As I was implementing this for
    a profile using the apache module, I realized that I could make another
    refinement to our approach by using
    create_resources('class','<module name>') to pull our hiera data into the
    apache class and override any defaults needed.
    It looks good to me but there are some concerns that it will come back and
    bite us in ways we don't expect
    later on, when updating to Puppet 3.0.

    Good news: it's unlikely that this will bite you later on.
    Bad news: that's because it will bite you now.

    Classes are not resources, and the create_resources() function does not
    work with them.


    John


    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/cfY5ydWGjNoJ.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • R.I.Pienaar at Jan 14, 2013 at 3:32 pm

    ----- Original Message -----
    From: "jcbollinger" <john.bollinger@stjude.org>
    To: puppet-users@googlegroups.com
    Sent: Monday, January 14, 2013 3:25:34 PM
    Subject: [Puppet Users] Re: Profiles, Hiera, and create_resources('class','...')


    On Friday, January 11, 2013 2:14:46 PM UTC-6, Eric Sakowski wrote:

    Hi all,

    We've recently started exploring the role / profile / component module
    described by Craig Dunn in his blog here:
    http://www.craigdunn.org/2012/05/239/ and discussed on the list the other
    day. As I was implementing this for
    a profile using the apache module, I realized that I could make another
    refinement to our approach by using
    create_resources('class','<module name>') to pull our hiera data into the
    apache class and override any defaults needed.
    It looks good to me but there are some concerns that it will come back and
    bite us in ways we don't expect
    later on, when updating to Puppet 3.0.

    Good news: it's unlikely that this will bite you later on.
    Bad news: that's because it will bite you now.

    Classes are not resources, and the create_resources() function does not
    work with them.
    sure it does - just like any other resources.

    class x($msg) { notify{$msg: } }

    create_resources("class", {"x" => {"msg" => "hello world"}})

    will produce:

    Notice: hello world
    Notice: /Stage[main]/X/Notify[hello world]/message: defined 'message' as 'hello world'

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Jcbollinger at Jan 14, 2013 at 3:45 pm

    On Monday, January 14, 2013 9:32:52 AM UTC-6, R.I. Pienaar wrote:

    ----- Original Message -----
    From: "jcbollinger"
    To: puppet...@googlegroups.com <javascript:>
    Sent: Monday, January 14, 2013 3:25:34 PM
    Subject: [Puppet Users] Re: Profiles, Hiera, and
    create_resources('class','...')

    On Friday, January 11, 2013 2:14:46 PM UTC-6, Eric Sakowski wrote:

    Hi all,

    We've recently started exploring the role / profile / component module
    described by Craig Dunn in his blog here:
    http://www.craigdunn.org/2012/05/239/ and discussed on the list the
    other
    day. As I was implementing this for
    a profile using the apache module, I realized that I could make
    another
    refinement to our approach by using
    create_resources('class','<module name>') to pull our hiera data into
    the
    apache class and override any defaults needed.
    It looks good to me but there are some concerns that it will come back
    and
    bite us in ways we don't expect
    later on, when updating to Puppet 3.0.

    Good news: it's unlikely that this will bite you later on.
    Bad news: that's because it will bite you now.

    Classes are not resources, and the create_resources() function does not
    work with them.
    sure it does - just like any other resources.

    class x($msg) { notify{$msg: } }

    create_resources("class", {"x" => {"msg" => "hello world"}})

    will produce:

    Notice: hello world
    Notice: /Stage[main]/X/Notify[hello world]/message: defined 'message'
    as 'hello world'

    My apologies, then. That did not always work. The issue has come up here,
    I think within the past year. Do you know when it changed?


    John

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/TppS_7BFB9IJ.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • R.I.Pienaar at Jan 14, 2013 at 3:49 pm

    ----- Original Message -----
    From: "jcbollinger" <john.bollinger@stjude.org>
    To: puppet-users@googlegroups.com
    Sent: Monday, January 14, 2013 3:43:49 PM
    Subject: Re: [Puppet Users] Re: Profiles, Hiera, and create_resources('class','...')


    On Monday, January 14, 2013 9:32:52 AM UTC-6, R.I. Pienaar wrote:


    ----- Original Message -----
    From: "jcbollinger"
    To: puppet...@googlegroups.com <javascript:>
    Sent: Monday, January 14, 2013 3:25:34 PM
    Subject: [Puppet Users] Re: Profiles, Hiera, and
    create_resources('class','...')

    On Friday, January 11, 2013 2:14:46 PM UTC-6, Eric Sakowski wrote:

    Hi all,

    We've recently started exploring the role / profile / component module
    described by Craig Dunn in his blog here:
    http://www.craigdunn.org/2012/05/239/ and discussed on the list the
    other
    day. As I was implementing this for
    a profile using the apache module, I realized that I could make
    another
    refinement to our approach by using
    create_resources('class','<module name>') to pull our hiera data into
    the
    apache class and override any defaults needed.
    It looks good to me but there are some concerns that it will come back
    and
    bite us in ways we don't expect
    later on, when updating to Puppet 3.0.

    Good news: it's unlikely that this will bite you later on.
    Bad news: that's because it will bite you now.

    Classes are not resources, and the create_resources() function does not
    work with them.
    sure it does - just like any other resources.

    class x($msg) { notify{$msg: } }

    create_resources("class", {"x" => {"msg" => "hello world"}})

    will produce:

    Notice: hello world
    Notice: /Stage[main]/X/Notify[hello world]/message: defined 'message'
    as 'hello world'

    My apologies, then. That did not always work. The issue has come up here,
    I think within the past year. Do you know when it changed?
    No I am not sure - I dont tend to use create_resources as I consider it about
    as bad as eval() :)

    I just know I recently went spelunking into that code while doing some prototype
    and noticed it worked

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • GRANIER Bernard (MORPHO) at Jan 14, 2013 at 3:59 pm
    Due to internet policy of my company, I can not access to gepetto install site thru eclipse.

    Is it possible to download gepetto plugin as a zip ? I mean not a full eclipse but just the plugin.

    Cordialement,

    Bernard Granier
    CE Plateforme Système
    bernard.granier@morpho.com
    01 58 11 32 51


    #
    " This e-mail and any attached documents may contain confidential or proprietary information. If you are not the intended recipient, you are notified that any dissemination, copying of this e-mail and any attachments thereto or use of their contents by any means whatsoever is strictly prohibited. If you have received this e-mail in error, please advise the sender immediately and delete this e-mail and all attached documents from your computer system."
    #

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Henrik Lindberg at Jan 14, 2013 at 4:38 pm

    On 2013-14-01 16:58, GRANIER Bernard (MORPHO) wrote:
    Due to internet policy of my company, I can not access to gepetto install site thru eclipse.

    Is it possible to download gepetto plugin as a zip ? I mean not a full eclipse but just the plugin.
    It is not available to the public, please contact me directly and I will
    help you out. (Email or on #geppetto on IRC)

    Supposedly it should also be possible to install into an Eclipse IDE
    from the pacakged Geppetto by refering to its location in Eclipse - but
    have not tried this.

    Longer term we will make the repository itself available. We intended to
    put it up on github download, but now that service has been deprecated
    and we are looking for a new download home.


    Regards
    - henrik


    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • GRANIER Bernard (MORPHO) at Jan 14, 2013 at 4:48 pm
    My mail is bernard.granier@morpho.com

    Cordialement,

    Bernard Granier
    CE Plateforme Système
    bernard.granier@morpho.com
    01 58 11 32 51


    -----Original Message-----
    From: puppet-users@googlegroups.com On Behalf Of Henrik Lindberg
    Sent: Monday, January 14, 2013 5:38 PM
    To: puppet-users@googlegroups.com
    Subject: Re: [Puppet Users] geppeto packaging
    On 2013-14-01 16:58, GRANIER Bernard (MORPHO) wrote:
    Due to internet policy of my company, I can not access to gepetto install site thru eclipse.

    Is it possible to download gepetto plugin as a zip ? I mean not a full eclipse but just the plugin.
    It is not available to the public, please contact me directly and I will
    help you out. (Email or on #geppetto on IRC)

    Supposedly it should also be possible to install into an Eclipse IDE
    from the pacakged Geppetto by refering to its location in Eclipse - but
    have not tried this.

    Longer term we will make the repository itself available. We intended to
    put it up on github download, but now that service has been deprecated
    and we are looking for a new download home.


    Regards
    - henrik


    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

    #
    " This e-mail and any attached documents may contain confidential or proprietary information. If you are not the intended recipient, you are notified that any dissemination, copying of this e-mail and any attachments thereto or use of their contents by any means whatsoever is strictly prohibited. If you have received this e-mail in error, please advise the sender immediately and delete this e-mail and all attached documents from your computer system."
    #

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Jcbollinger at Jan 14, 2013 at 4:23 pm

    On Monday, January 14, 2013 9:49:33 AM UTC-6, R.I. Pienaar wrote:

    No I am not sure - I dont tend to use create_resources as I consider it
    about
    as bad as eval() :)

    I just know I recently went spelunking into that code while doing some
    prototype
    and noticed it worked

    Bottom line, then: it will bite the OP either now or later, or maybe even
    both.


    John

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/KlgdS1DEv5YJ.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Stephen Price at Jan 16, 2013 at 4:52 pm

    On Monday, January 14, 2013 7:49:33 AM UTC-8, R.I. Pienaar wrote:
    No I am not sure - I dont tend to use create_resources as I consider it
    about
    as bad as eval() :)

    I just know I recently went spelunking into that code while doing some
    prototype
    and noticed it worked
    Sorry to derail this discussion, but R.I., what is it that you find bad
    about create_resources? I've found it invaluable when creating resources
    from definitions.

    For example, I have an apache::conf definition for a config file, and I
    create a hash for each config file I want created on the node. Then just
    use "create_resources(apache::conf, $apache_conf_hash)" in the module's
    init.pp.

    How would you do it otherwise? Documentation on Hiera is pretty lacking
    right now, and it's the best method I've found for this sort of thing.

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/zt2SdyPBJxsJ.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Jcbollinger at Jan 14, 2013 at 4:17 pm

    On Friday, January 11, 2013 2:14:46 PM UTC-6, Eric Sakowski wrote:
    Hi all,

    We've recently started exploring the role / profile / component module
    described by Craig Dunn in his blog here:
    http://www.craigdunn.org/2012/05/239/ and discussed on the list the other
    day. As I was implementing this for
    a profile using the apache module, I realized that I could make another
    refinement to our approach by using
    create_resources('class','<module name>') to pull our hiera data into the
    apache class and override any defaults needed.
    It looks good to me but there are some concerns that it will come back and
    bite us in ways we don't expect
    later on, when updating to Puppet 3.0. The benefit right away is that it
    saves us from having to even touch
    puppet forge modules to 'hierafy' them, and it is much less code to write
    and maintain, simply by structuring
    class param hiera data as a hash of key-value pairs instead of flat
    key-value pairs in the yaml. Any guidance
    or warnings or comments in general would be most helpful to us in deciding
    how to go forward.

    Accepting R.I. that the approach won't break outright, I'll take up the
    question of subtle bite-us-later issues, plus some other issues.

    First, do note that the second argument to create_resources() is not
    expected to be a plain resource name: it is expected to be a hash, whose
    keys are names of resources to create and whose values are hashes of
    resource parameter mappings. (Perhaps you already understand that and were
    merely shortcutting.) Perhaps it would work with scalars as shown, but it
    is better to use the 'include' function if you do not intend to declare
    class parameters.

    Second, be aware that in Puppet 3, you already don't need to do anything
    special in your manifests to hierify the parameters of parametrized
    classes. Puppet 3 will automatically consult hiera for class parameter
    values, using keys based on the class and parameter names. This is one of
    Puppet 3's best advances.

    Although parametrized classes work fine in Puppet 3 with hiera-based
    parameter lookup, the same is not true of classes declared with local
    parameter customizations via parametrized-class syntax (in any Puppet
    version since parametrized classes were introduced). The problems with
    such declarations must also apply if you use the create_resources()
    function to set class parameters.

    The most important problem there that classes may be declared any number of
    times -- and there are good reasons for multiple declarations of the same
    class -- but only the first declaration parsed may declare explicit
    parameters. Furthermore, Puppet's parse order can be difficult to predict
    (indeed, controlling parse order is one of the most important reasons for
    multiple class declarations) so it may be tricky to be confident that any
    particular declaration will be parsed first.

    Even if your create_resources() appears at top scope or in a node block,
    you could still be bitten by the multiple-declaration issue if one of the
    modules you declare that way itself declares one of the others that you
    declare later. Worse (in this regard), if you declare multiple classes in
    the same declare_resources() call, then you absolutely cannot predict the
    order in which those classes will be declared.

    If, on the other hand, you use create_resources() to declare one class at a
    time, then you gain little. Plain 'include' combined with Puppet 3's
    parameter autolookup would serve you better for that purpose.


    John

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/4v38QVt8GagJ.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Eric Sakowski at Jan 14, 2013 at 5:08 pm

    On Monday, January 14, 2013 11:17:47 AM UTC-5, jcbollinger wrote:

    On Friday, January 11, 2013 2:14:46 PM UTC-6, Eric Sakowski wrote:

    Hi all,

    We've recently started exploring the role / profile / component module
    described by Craig Dunn in his blog here:
    http://www.craigdunn.org/2012/05/239/ and discussed on the list the
    other day. As I was implementing this for
    a profile using the apache module, I realized that I could make another
    refinement to our approach by using
    create_resources('class','<module name>') to pull our hiera data into the
    apache class and override any defaults needed.
    It looks good to me but there are some concerns that it will come back
    and bite us in ways we don't expect
    later on, when updating to Puppet 3.0. The benefit right away is that it
    saves us from having to even touch
    puppet forge modules to 'hierafy' them, and it is much less code to write
    and maintain, simply by structuring
    class param hiera data as a hash of key-value pairs instead of flat
    key-value pairs in the yaml. Any guidance
    or warnings or comments in general would be most helpful to us in
    deciding how to go forward.

    Accepting R.I. that the approach won't break outright, I'll take up the
    question of subtle bite-us-later issues, plus some other issues.
    Thanks John for the reply. It definitely works. The code I posted was
    copied from a working setup, not pseudo-code.

    First, do note that the second argument to create_resources() is not
    expected to be a plain resource name: it is expected to be a hash, whose
    keys are names of resources to create and whose values are hashes of
    resource parameter mappings. (Perhaps you already understand that and were
    merely shortcutting.) Perhaps it would work with scalars as shown, but it
    is better to use the 'include' function if you do not intend to declare
    class parameters.
    Understood. apache_params is a hash containing key apache w/ value <hash
    of apache values from hiera>

    Second, be aware that in Puppet 3, you already don't need to do anything
    special in your manifests to hierify the parameters of parametrized
    classes. Puppet 3 will automatically consult hiera for class parameter
    values, using keys based on the class and parameter names. This is one of
    Puppet 3's best advances.
    OK, so given that I am a user of the apache module, and it is parameterized
    already when I install it, for Puppet 3.0 then I could simply drop
    create_resources call and Puppet 3 will automatically look it up in hiera?

    Although parametrized classes work fine in Puppet 3 with hiera-based
    parameter lookup, the same is not true of classes declared with local
    parameter customizations via parametrized-class syntax (in any Puppet
    version since parametrized classes were introduced). The problems with
    such declarations must also apply if you use the create_resources()
    function to set class parameters.

    The most important problem there that classes may be declared any number
    of times -- and there are good reasons for multiple declarations of the
    same class -- but only the first declaration parsed may declare explicit
    parameters. Furthermore, Puppet's parse order can be difficult to predict
    (indeed, controlling parse order is one of the most important reasons for
    multiple class declarations) so it may be tricky to be confident that any
    particular declaration will be parsed first.
    OK. Sounds like having my defaults come from the apache modules parameter
    declarations may be a problem in Puppet 3.0. I am installing a Puppet 3
    master to try and test this. Any suggestions on how best to set up the
    error condition you describe? I have run across some error messages from
    puppet rdoc finding multiple class declarations. I'd like to better
    understand what you're talking about here -- I'll go google but any links
    would be appreciated!

    Even if your create_resources() appears at top scope or in a node block,
    you could still be bitten by the multiple-declaration issue if one of the
    modules you declare that way itself declares one of the others that you
    declare later. Worse (in this regard), if you declare multiple classes in
    the same declare_resources() call, then you absolutely cannot predict the
    order in which those classes will be declared.

    If, on the other hand, you use create_resources() to declare one class at
    a time, then you gain little. Plain 'include' combined with Puppet 3's
    parameter autolookup would serve you better for that purpose.

    That sounds great and probably what I will do when we eventually upgrade
    to Puppet 3. Basically just drop the calls to create_resources and simply
    include.

    John
    Thanks again,
    Eric


    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/6PhlxckuKhMJ.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Jcbollinger at Jan 15, 2013 at 3:44 pm

    On Monday, January 14, 2013 11:00:42 AM UTC-6, Eric Sakowski wrote:

    [...]
    OK, so given that I am a user of the apache module, and it is
    parameterized already when I install it, for Puppet 3.0 then I could simply
    drop create_resources call and Puppet 3 will automatically look it up in
    hiera?

    That is correct. Just use this:

    include 'apache'

    In addition, you will need to structure your hiera data slightly
    differently. Instead of collecting the class parameters in a hash, they
    need to be (namespaced) top-level data:

    apache::default_mods : true
    apache::default_vhost : false
    apache::default_ssl_vhost : false
    apache::service_enable : true
    apache::serveradmin : 'root@localhost'
    apache::sendfile : false
    apache::error_pages : false

    Note that the namespace prefix is just part of the keys as far as hiera is
    concerned; the magic happens on the Puppet side.


    [...]
    OK. Sounds like having my defaults come from the apache modules parameter
    declarations may be a problem in Puppet 3.0.


    Not at all. Puppet will fall back to the default (if any) in the class
    definition if hiera does not provide a value for a given parameter. The
    precedence is: explicit parameters in your class declaration (do not use)
    parameters read from hiera > parameters in the class definition > undef.
    Puppet uses the first one found, on a parameter-by-parameter basis.


    I am installing a Puppet 3 master to try and test this. Any suggestions
    on how best to set up the error condition you describe? I have run across
    some error messages from puppet rdoc finding multiple class declarations.
    I'd like to better understand what you're talking about here -- I'll go
    google but any links would be appreciated!

    A simple, but very synthetic test case would be:

    node test {
    include 'apache'
    class { 'apache': service_enable => true }
    }

    where you test with a node 'test'. Replace the "class ..." line with your
    create_resources() call to test that flavor. Note also that order matters:
    if you swap the "include" and "class" lines then it should work. On the
    other hand, it should not work if you change the "include" line to a copy
    of the "class" line: multiple parametrized-style declarations of the same
    classes are not forbidden even when the parameter lists match (except maybe
    where no parameters are explicitly declared at all).


    That sounds great and probably what I will do when we eventually upgrade
    to Puppet 3. Basically just drop the calls to create_resources and simply
    include.
    Yes, that is precisely my recommendation.


    Best,

    John

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/fqQc_soJ34EJ.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Jcbollinger at Jan 16, 2013 at 3:43 pm

    On Tuesday, January 15, 2013 9:44:00 AM UTC-6, jcbollinger wrote:
    [...] multiple parametrized-style declarations of the same classes are not
    forbidden even when the parameter lists match
    Clarification: there is an extraneous "not" in there. It should have been
    "multiple parametrized-style declarations of the same classes *are*forbidden even when the parameter lists match."


    John

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/6xnq75hvuVYJ.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedJan 11, '13 at 8:51p
activeJan 16, '13 at 4:52p
posts14
users6
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase