FAQ
Dear,

I've been using puppet for some time now. Usually when I have a problem I
read all documentation refered to the problem I have.

Recently I was trying to write a puppet erb template, that checks if host
has one class defined, and if it has then writes some text to cron.

After a lot of googleing, I found that the best way to do this was:

<% if classes.include?( 'class1' ) -%>
Some text
<% end -%>

And this worked.

But when I try on the same erb file to look for other classes, then it only
processes 1:
<% if classes.include?( 'class1' ) -%>
Some text
<% end -%>
<% if classes.include?( 'class2' ) -%>
Blah Blah Blah
<% end -%>

I can find only "Some text" inside file. But this host has class2 also
declared. If I remove if classes.include of class1, and leave alone class2
text, then I can see the text of class2.

Did anyone had this issue before?

Thanks for your time.

--
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+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Jcbollinger at Feb 14, 2013 at 8:09 pm

    On Thursday, February 14, 2013 10:35:50 AM UTC-6, Marc Bolós wrote:
    Dear,

    I've been using puppet for some time now. Usually when I have a problem I
    read all documentation refered to the problem I have.

    Recently I was trying to write a puppet erb template, that checks if host
    has one class defined, and if it has then writes some text to cron.

    After a lot of googleing, I found that the best way to do this was:

    Maybe, but better by far is to avoid doing that at all. Specifically,
    avoid writing DSL code or templates that attempt to inquire whether
    particular resources have been declared. Such code is inherently
    parse-order sensitive, and it is, moreover, unnecessary. Although it may
    at some times seem convenient, it is never *necessary* to inquire whether a
    given class or resource is (supposed to have been) declared. You can
    always know, whether in an absolute or a conditional sense.


    <% if classes.include?( 'class1' ) -%>
    Some text
    <% end -%>

    And this worked.

    But when I try on the same erb file to look for other classes, then it
    only processes 1:
    <% if classes.include?( 'class1' ) -%>
    Some text
    <% end -%>
    <% if classes.include?( 'class2' ) -%>
    Blah Blah Blah
    <% end -%>

    I can find only "Some text" inside file. But this host has class2 also
    declared. If I remove if classes.include of class1, and leave alone class2
    text, then I can see the text of class2.

    Did anyone had this issue before?
    In all likelihood, this is a parse-order problem. If the template() or
    inline_template() call by which you are evaluating the template is parsed
    before class2 has been assigned to the target node, then the template will
    not see it in the 'classes' array. Such problems can sometimes be managed,
    but even then there is usually a better approach.

    Inasmuch as your example is pretty synthetic, I can't say what a better
    approach would be. If you describe your real problem more then we might
    have better suggestions.


    John

    --
    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+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Marc Bolós at Feb 15, 2013 at 10:18 am
    Dear John,

    Thanks for your response.

    Since I have a large environment setup I was trying to automatize all
    setups from puppet, being as much simple as I can.

    For example, let's think that I have a puppet server and more than 1000
    puppet nodes. So I edit nodes.pp and I declare "server1" and I assign it an
    "apache2" module, a "bind9" module and an "ssh" module.

    Once this is working I try and create a shorewall firewall erb template for
    its rules file, so that it can automatically detect which modules are
    declared on the host, and write the relevant lines in the rules file to
    open the appropriate ports depending on that. In this example, the erb
    template for shorewall rules would be something like:

    ################################################################################
    # This file is centrally mantained by puppet, built from a template located
    at #
    # Path to file #
    ################################################################################
    <% if classes.include?('apache') -%>
    HTTP(ACCEPT) net $FW
    <% end -%>
    <% if classes.include?('bind') -%>
    DNS/ACCEPT net $FW
    <% end -%>
    <% if classes.include?('ssh') -%>
    SSH/ACCEPT net:someips $FW
    <% end -%>

    But this does not work for me. Could you provide me another clean and smart
    way of achieving that? (Our goal would be not having to declare the whole
    bunch of servers more than once, even in the nodes.pp file or in any other
    place).




    El jueves, 14 de febrero de 2013 17:35:50 UTC+1, Marc Bolós escribió:
    Dear,

    I've been using puppet for some time now. Usually when I have a problem I
    read all documentation refered to the problem I have.

    Recently I was trying to write a puppet erb template, that checks if host
    has one class defined, and if it has then writes some text to cron.

    After a lot of googleing, I found that the best way to do this was:

    <% if classes.include?( 'class1' ) -%>
    Some text
    <% end -%>

    And this worked.

    But when I try on the same erb file to look for other classes, then it
    only processes 1:
    <% if classes.include?( 'class1' ) -%>
    Some text
    <% end -%>
    <% if classes.include?( 'class2' ) -%>
    Blah Blah Blah
    <% end -%>

    I can find only "Some text" inside file. But this host has class2 also
    declared. If I remove if classes.include of class1, and leave alone class2
    text, then I can see the text of class2.

    Did anyone had this issue before?

    Thanks for your time.
    --
    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+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jcbollinger at Feb 15, 2013 at 3:09 pm

    On Friday, February 15, 2013 4:18:20 AM UTC-6, Marc Bolós wrote:
    Dear John,

    Thanks for your response.

    Since I have a large environment setup I was trying to automatize all
    setups from puppet, being as much simple as I can.

    For example, let's think that I have a puppet server and more than 1000
    puppet nodes. So I edit nodes.pp and I declare "server1" and I assign it an
    "apache2" module, a "bind9" module and an "ssh" module.

    Once this is working I try and create a shorewall firewall erb template
    for its rules file, so that it can automatically detect which modules are
    declared on the host, and write the relevant lines in the rules file to
    open the appropriate ports depending on that. In this example, the erb
    template for shorewall rules would be something like:


    ################################################################################
    # This file is centrally mantained by puppet, built from a template
    located at #
    # Path to file #

    ################################################################################
    <% if classes.include?('apache') -%>
    HTTP(ACCEPT) net $FW
    <% end -%>
    <% if classes.include?('bind') -%>
    DNS/ACCEPT net $FW
    <% end -%>
    <% if classes.include?('ssh') -%>
    SSH/ACCEPT net:someips $FW
    <% end -%>

    But this does not work for me. Could you provide me another clean and
    smart way of achieving that? (Our goal would be not having to declare the
    whole bunch of servers more than once, even in the nodes.pp file or in any
    other place).




    El jueves, 14 de febrero de 2013 17:35:50 UTC+1, Marc Bolós escribió:
    Dear,

    I've been using puppet for some time now. Usually when I have a problem I
    read all documentation refered to the problem I have.

    Recently I was trying to write a puppet erb template, that checks if host
    has one class defined, and if it has then writes some text to cron.

    After a lot of googleing, I found that the best way to do this was:

    <% if classes.include?( 'class1' ) -%>
    Some text
    <% end -%>

    And this worked.

    But when I try on the same erb file to look for other classes, then it
    only processes 1:
    <% if classes.include?( 'class1' ) -%>
    Some text
    <% end -%>
    <% if classes.include?( 'class2' ) -%>
    Blah Blah Blah
    <% end -%>

    I can find only "Some text" inside file. But this host has class2 also
    declared. If I remove if classes.include of class1, and leave alone class2
    text, then I can see the text of class2.

    Did anyone had this issue before?

    Thanks for your time.
    There are basically two good ways to approach this:

    1. Have your service modules (apache2, bind9, ssh) each export an
    appropriate fragment of the FW configuration (using fragment resource types
    provided by the Puppet::Concat add-in module), or
    2. use the same data or logic by which you chose to include those
    modules on a given node in the first place to drive which sections are
    included in the FW config file.

    If there are nodes on which you do not configure a firewall, then as a
    variation on option (1), you can declare the fragments as virtual
    resources, to be realized only on those nodes with FW.

    There are a lot of ways you could do (2), but one might be

    manifests/site.pp:
    --------
    node somenode {
    $service_modules = hiera_array('service_modules')

    include $service_modules
    include firewall
    }

    modules/firewall/manifests/init.pp
    --------
    class firewall {
    $service_modules = hiera_array('service_modules')
    # other classes
    file { 'firewall-rules-filename':
    # other properties
    content => template('config.erb')
    }
    }

    modules/firewall/templates/config.erb
    --------
    <% if @service_modules.include?('apache2') -%>
    # config-for-apache2
    <% end -%>
    <% if @service_modules.include?('bind9') -%>
    # config-for-bind9
    <% end -%>
    <% if @service_modules.include?('ssh') -%>
    # config-for-ssh
    <% end -%>


    Yes, that template looks a lot like your original. The key difference is
    the data source on which it is drawing: not a list of classes that *have
    been *assigned by that point in the catalog compilation process, but rather
    a list of relevant classes that *will have been* assigned by the end of
    catalog compilation. Furthermore, it's all based on on the same data, so
    there is no risk of your module list falling out of sync with your firewall
    config.

    Although I use hiera in the example, I hope you recognize that that's an
    implementation detail (albeit a convenient one), not an essential element.


    John

    --
    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+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Marc Bolós at Feb 15, 2013 at 4:57 pm
    Dear John,

    I tryed as you suggested but I think I'm doing something wrong.

    I can also see this line is same:
    $service_modules = hiera_array('service_modules')

    It is correct?

    Where do I define array of modules? where you write service_modules?

    Regards.


    manifests/site.pp:
    --------
    node somenode {
    $service_modules = hiera_array('service_modules')

    include $service_modules
    include firewall
    }

    modules/firewall/manifests/init.pp
    --------
    class firewall {
    $service_modules = hiera_array('service_modules')
    # other classes
    file { 'firewall-rules-filename':
    # other properties
    content => template('config.erb')
    }
    }

    modules/firewall/templates/config.erb
    --------
    <% if @service_modules.include?('apache2') -%>
    # config-for-apache2
    <% end -%>
    <% if @service_modules.include?('bind9') -%>
    # config-for-bind9
    <% end -%>
    <% if @service_modules.include?('ssh') -%>
    # config-for-ssh
    <% end -%>


    El viernes, 15 de febrero de 2013 16:09:38 UTC+1, jcbollinger escribió:

    On Friday, February 15, 2013 4:18:20 AM UTC-6, Marc Bolós wrote:

    Dear John,

    Thanks for your response.

    Since I have a large environment setup I was trying to automatize all
    setups from puppet, being as much simple as I can.

    For example, let's think that I have a puppet server and more than 1000
    puppet nodes. So I edit nodes.pp and I declare "server1" and I assign it an
    "apache2" module, a "bind9" module and an "ssh" module.

    Once this is working I try and create a shorewall firewall erb template
    for its rules file, so that it can automatically detect which modules are
    declared on the host, and write the relevant lines in the rules file to
    open the appropriate ports depending on that. In this example, the erb
    template for shorewall rules would be something like:


    ################################################################################
    # This file is centrally mantained by puppet, built from a template
    located at #
    # Path to file #

    ################################################################################
    <% if classes.include?('apache') -%>
    HTTP(ACCEPT) net $FW
    <% end -%>
    <% if classes.include?('bind') -%>
    DNS/ACCEPT net $FW
    <% end -%>
    <% if classes.include?('ssh') -%>
    SSH/ACCEPT net:someips $FW
    <% end -%>

    But this does not work for me. Could you provide me another clean and
    smart way of achieving that? (Our goal would be not having to declare the
    whole bunch of servers more than once, even in the nodes.pp file or in any
    other place).




    El jueves, 14 de febrero de 2013 17:35:50 UTC+1, Marc Bolós escribió:
    Dear,

    I've been using puppet for some time now. Usually when I have a problem
    I read all documentation refered to the problem I have.

    Recently I was trying to write a puppet erb template, that checks if
    host has one class defined, and if it has then writes some text to cron.

    After a lot of googleing, I found that the best way to do this was:

    <% if classes.include?( 'class1' ) -%>
    Some text
    <% end -%>

    And this worked.

    But when I try on the same erb file to look for other classes, then it
    only processes 1:
    <% if classes.include?( 'class1' ) -%>
    Some text
    <% end -%>
    <% if classes.include?( 'class2' ) -%>
    Blah Blah Blah
    <% end -%>

    I can find only "Some text" inside file. But this host has class2 also
    declared. If I remove if classes.include of class1, and leave alone class2
    text, then I can see the text of class2.

    Did anyone had this issue before?

    Thanks for your time.
    There are basically two good ways to approach this:

    1. Have your service modules (apache2, bind9, ssh) each export an
    appropriate fragment of the FW configuration (using fragment resource types
    provided by the Puppet::Concat add-in module), or
    2. use the same data or logic by which you chose to include those
    modules on a given node in the first place to drive which sections are
    included in the FW config file.

    If there are nodes on which you do not configure a firewall, then as a
    variation on option (1), you can declare the fragments as virtual
    resources, to be realized only on those nodes with FW.

    There are a lot of ways you could do (2), but one might be

    manifests/site.pp:
    --------
    node somenode {
    $service_modules = hiera_array('service_modules')

    include $service_modules
    include firewall
    }

    modules/firewall/manifests/init.pp
    --------
    class firewall {
    $service_modules = hiera_array('service_modules')
    # other classes
    file { 'firewall-rules-filename':
    # other properties
    content => template('config.erb')
    }
    }

    modules/firewall/templates/config.erb
    --------
    <% if @service_modules.include?('apache2') -%>
    # config-for-apache2
    <% end -%>
    <% if @service_modules.include?('bind9') -%>
    # config-for-bind9
    <% end -%>
    <% if @service_modules.include?('ssh') -%>
    # config-for-ssh
    <% end -%>


    Yes, that template looks a lot like your original. The key difference is
    the data source on which it is drawing: not a list of classes that *have
    been *assigned by that point in the catalog compilation process, but
    rather a list of relevant classes that *will have been* assigned by the
    end of catalog compilation. Furthermore, it's all based on on the same
    data, so there is no risk of your module list falling out of sync with your
    firewall config.

    Although I use hiera in the example, I hope you recognize that that's an
    implementation detail (albeit a convenient one), not an essential element.


    John
    --
    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+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jcbollinger at Feb 15, 2013 at 8:10 pm

    On Friday, February 15, 2013 10:51:06 AM UTC-6, Marc Bolós wrote:
    Dear John,

    I tryed as you suggested but I think I'm doing something wrong.

    I can also see this line is same:
    $service_modules = hiera_array('service_modules')

    It is correct?

    Where do I define array of modules? where you write service_modules?

    The code was intended as an example. If you want to use it exactly as
    written, then you must configure Puppet's "hiera" external data subsystem
    on the master, and record the module list in a hiera data file (supposing
    you use the YAML back end). That has a lot of advantages, but if you don't
    know what I'm talking about then you might be better off starting simpler.

    A very simple proof of concept would be to put

    $fw_modules = ['apache2', 'bind9', 'ssh']

    (or whatever module list you want) at the beginning of your
    manifests/site.pp (outside any node block), and replace each of the two
    lines invoking hiera_array() with this:

    $service_modules = $::fw_modules

    Once you've satisfied yourself that it works (which it should), you can
    figure out a more appropriate way to declare the shared data.


    John

    --
    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+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Marc Bolós at Feb 18, 2013 at 1:17 pm
    Dear John,

    I tryed as you suggested, and didn't work.

    I Found where is the problem that produces the failure in both cases. The
    problem basically is that on all the nodes I'm using inherits definition
    like:

    node basenode {
    include shorewall
    include othermodules
    }

    node examplenode1 inherits basenode {
    include apache
    include bind
    include ssh
    }

    So I tryed debugging and on the template I added following lines:

    <% classes.each do |k| -%>
    <%= k %>
    <% end -%>

    Then I find that it only prints classes inside basenode:
    shorewall
    other modules

    If I declare host without inherits then, both procedures works, my first
    and yours. And in this example , classes will print:
    shorewall
    other modules
    apache
    bind
    ssh

    It is pretty clear to me that this seems a puppet bug that does not parse
    properly classes when you are using inherits in site.pp manifets.

    El viernes, 15 de febrero de 2013 21:10:41 UTC+1, jcbollinger escribió:

    On Friday, February 15, 2013 10:51:06 AM UTC-6, Marc Bolós wrote:

    Dear John,

    I tryed as you suggested but I think I'm doing something wrong.

    I can also see this line is same:
    $service_modules = hiera_array('service_modules')

    It is correct?

    Where do I define array of modules? where you write service_modules?

    The code was intended as an example. If you want to use it exactly as
    written, then you must configure Puppet's "hiera" external data subsystem
    on the master, and record the module list in a hiera data file (supposing
    you use the YAML back end). That has a lot of advantages, but if you don't
    know what I'm talking about then you might be better off starting simpler.

    A very simple proof of concept would be to put

    $fw_modules = ['apache2', 'bind9', 'ssh']

    (or whatever module list you want) at the beginning of your
    manifests/site.pp (outside any node block), and replace each of the two
    lines invoking hiera_array() with this:

    $service_modules = $::fw_modules

    Once you've satisfied yourself that it works (which it should), you can
    figure out a more appropriate way to declare the shared data.


    John
    --
    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+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jcbollinger at Feb 19, 2013 at 4:21 pm

    On Monday, February 18, 2013 7:17:51 AM UTC-6, Marc Bolós wrote:
    Dear John,

    I tryed as you suggested, and didn't work.

    Well no, evidently you didn't do what I suggested.


    I Found where is the problem that produces the failure in both cases. The
    problem basically is that on all the nodes I'm using inherits definition
    like:

    node basenode {
    include shorewall
    include othermodules
    }

    node examplenode1 inherits basenode {
    include apache
    include bind
    include ssh
    }
    The most essential part of my suggestion was that the "include firewall" be
    parsed *after* "include $service_modules". The example code achieves that
    by putting the former after the latter in the same node block. Putting the
    two in different node blocks, with the latter's inheriting from the
    former's, on the other hand, ensures the opposite (i.e. wrong) parse order.


    So I tryed debugging and on the template I added following lines:

    <% classes.each do |k| -%>
    <%= k %>
    <% end -%>

    Then I find that it only prints classes inside basenode:
    shorewall
    other modules

    If I declare host without inherits then, both procedures works, my first
    and yours. And in this example , classes will print:
    shorewall
    other modules
    apache
    bind
    ssh

    It is pretty clear to me that this seems a puppet bug that does not parse
    properly classes when you are using inherits in site.pp manifets.

    No bug here. Puppet is behaving exactly as documented in the failing
    cases. When Puppet processes your template, the 'apache', 'bind', and
    'ssh' classes have not yet been declared, and therefore they do not appear
    in the 'classes' array. See
    http://docs.puppetlabs.com/guides/templating.html#access-to-tags-and-declared-classes,
    which documents the variable you are trying to use.

    Even when the classes are all declared in the same node block, I would
    expect that the apache, bind, and ssh 'include's would need to appear
    first. If you find that not to be the case then you have stumbled on a
    convenience feature.

    Now that you have had a taste of the pain, I repeat my initial advice:
    avoid writing DSL code or templates that attempt to inquire whether
    particular resources have been declared.


    John

    --
    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+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jcbollinger at Feb 19, 2013 at 4:48 pm

    On Tuesday, February 19, 2013 10:21:47 AM UTC-6, jcbollinger wrote:

    The most essential part of my suggestion was that the "include firewall"
    be parsed *after* "include $service_modules". The example code achieves
    that by putting the former after the latter in the same node block.
    Putting the two in different node blocks, with the latter's inheriting from
    the former's, on the other hand, ensures the opposite (i.e. wrong) parse
    order.
    Hmm. My recollection of what was going on here was faulty, and in fact
    that was not the essential point at all. Indeed, the whole idea was that
    class declaration order could be made to not matter. As a corollary, how
    class declarations are split among node blocks in a node inheritance chain
    can be made not to matter either.

    If something like my suggestion worked when all the classes were declared
    in the same node block, but not when they were split up as described, then
    I would guess that you omitted the declaration of the $service_modules
    variable in your 'firewall' class. If you then declare that class in a
    node block where a variable of the same name has been declared (including
    in a base node), then the class will draw on the node variable. Otherwise,
    the value is empty.

    Note in particular that declaring a class in the base node and setting a
    variable in a child node does not make the variable visible to that class.
    Node inheritance does not inject the inheriting node's variables into the
    scope of the inherited node.


    John

    --
    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+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Marc Bolós at Feb 22, 2013 at 10:20 am
    Dear John,

    Thanks a lot for your response. I found where was the problem and I have it
    working.

    The solituion consist in always declare shorewall as the last class and you
    can write erb template as my first example and will work.

    I wanted to thank you for all you help and time.

    So finally my conclusion is that when you declase a node, includes order
    matters.

    El martes, 19 de febrero de 2013 17:48:27 UTC+1, jcbollinger escribió:

    On Tuesday, February 19, 2013 10:21:47 AM UTC-6, jcbollinger wrote:


    The most essential part of my suggestion was that the "include firewall"
    be parsed *after* "include $service_modules". The example code achieves
    that by putting the former after the latter in the same node block.
    Putting the two in different node blocks, with the latter's inheriting from
    the former's, on the other hand, ensures the opposite (i.e. wrong) parse
    order.
    Hmm. My recollection of what was going on here was faulty, and in fact
    that was not the essential point at all. Indeed, the whole idea was that
    class declaration order could be made to not matter. As a corollary, how
    class declarations are split among node blocks in a node inheritance chain
    can be made not to matter either.

    If something like my suggestion worked when all the classes were declared
    in the same node block, but not when they were split up as described, then
    I would guess that you omitted the declaration of the $service_modules
    variable in your 'firewall' class. If you then declare that class in a
    node block where a variable of the same name has been declared (including
    in a base node), then the class will draw on the node variable. Otherwise,
    the value is empty.

    Note in particular that declaring a class in the base node and setting a
    variable in a child node does not make the variable visible to that class.
    Node inheritance does not inject the inheriting node's variables into the
    scope of the inherited node.


    John
    --
    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+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jcbollinger at Feb 22, 2013 at 6:19 pm

    On Friday, February 22, 2013 4:20:21 AM UTC-6, Marc Bolós wrote:

    So finally my conclusion is that when you declase a node, includes order
    matters.
    Yes, it does.


    John


    --
    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+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Felix Frank at Feb 25, 2013 at 12:51 pm

    On 02/22/2013 07:19 PM, jcbollinger wrote:
    So finally my conclusion is that when you declase a node, includes
    order matters.


    Yes, it does.
    ...but I'd argue that this should not be your final conclusion.

    It has been my experience (but this may be a question of manifest
    culture) that parse order cannot be predicted anymore once manifest
    complexity has reached a certain point. Think a network of dozens of
    modules that are intertwined.

    Therefor, what I take from reading this thread is: Do not try and build
    system configuration based on a list of included classes or similar
    meta-information.
    Instead, devise a mechanism that yields the needed information on a
    sound basis, that is less likely to break due to random manifest
    restructuring in the future.

    Cheers,
    Felix

    --
    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+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Marc Bolós at Feb 25, 2013 at 1:10 pm
    Felix,

    Thanks for your tips.


    2013/2/25 Felix Frank <felix.frank@alumni.tu-berlin.de>
    On 02/22/2013 07:19 PM, jcbollinger wrote:
    So finally my conclusion is that when you declase a node, includes
    order matters.


    Yes, it does.
    ...but I'd argue that this should not be your final conclusion.

    It has been my experience (but this may be a question of manifest
    culture) that parse order cannot be predicted anymore once manifest
    complexity has reached a certain point. Think a network of dozens of
    modules that are intertwined.

    Therefor, what I take from reading this thread is: Do not try and build
    system configuration based on a list of included classes or similar
    meta-information.
    Instead, devise a mechanism that yields the needed information on a
    sound basis, that is less likely to break due to random manifest
    restructuring in the future.

    Cheers,
    Felix

    --
    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+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.


    --
    "The computer security is an art form. It's the ultimate martial art."

    --
    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+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jcbollinger at Feb 26, 2013 at 2:04 pm

    On Monday, February 25, 2013 6:51:10 AM UTC-6, Felix.Frank wrote:
    On 02/22/2013 07:19 PM, jcbollinger wrote:
    So finally my conclusion is that when you declase a node, includes
    order matters.


    Yes, it does.
    ...but I'd argue that this should not be your final conclusion.

    Oh, I agree. I don't know whether you followed the whole thread, but my
    recommendation was always to solve the issue in a way that was independent
    of parse order. I suggested two general approaches to the problem and one
    specific implementation. I decided that the conversation was no longer
    worth my time when the OP "discovered" parse-order sensitivity some nine
    (combined) messages after I told him that was his problem in my first
    response to him.


    John

    --
    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+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Felix Frank at Feb 26, 2013 at 2:38 pm

    On 02/26/2013 03:04 PM, jcbollinger wrote:
    Oh, I agree. I don't know whether you followed the whole thread, but my
    recommendation was always to solve the issue in a way that was
    independent of parse order. I suggested two general approaches to the
    problem and one specific implementation. I decided that the
    conversation was no longer worth my time when the OP "discovered"
    parse-order sensitivity some nine (combined) messages after I told him
    that was his problem in my first response to him.
    Right. I guess what I was more or less trying to say was - it should
    have been done as was suggested (by you), not in yet a hodgepodge way
    that was found to be working in the end.

    Cheers,
    Felix

    --
    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+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Marc Bolós at Feb 26, 2013 at 4:01 pm
    So, your suggestion at the end, is better avoid doing that at all.

    Now I was very happy to have it working. The only issue I found was on the
    order declaring classes. I think maybe they should try to fix this, because
    you can make more powerful and automated declarations this way.

    Thanks a lot all for your suggestions.

    2013/2/26 Felix Frank <felix.frank@alumni.tu-berlin.de>
    On 02/26/2013 03:04 PM, jcbollinger wrote:
    Oh, I agree. I don't know whether you followed the whole thread, but my
    recommendation was always to solve the issue in a way that was
    independent of parse order. I suggested two general approaches to the
    problem and one specific implementation. I decided that the
    conversation was no longer worth my time when the OP "discovered"
    parse-order sensitivity some nine (combined) messages after I told him
    that was his problem in my first response to him.
    Right. I guess what I was more or less trying to say was - it should
    have been done as was suggested (by you), not in yet a hodgepodge way
    that was found to be working in the end.

    Cheers,
    Felix

    --
    You received this message because you are subscribed to a topic in the
    Google Groups "Puppet Users" group.
    To unsubscribe from this topic, visit
    https://groups.google.com/d/topic/puppet-users/kGrRmzTo_oY/unsubscribe?hl=en
    .
    To unsubscribe from this group and all its topics, send an email to
    puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.


    --
    "The computer security is an art form. It's the ultimate martial art."

    --
    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+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Marc Bolós at Feb 15, 2013 at 3:28 pm
    Dear John,

    I will try as you suggested, but it's pretty clear that this will work.

    Thanks a lot for your time.

    El jueves, 14 de febrero de 2013 17:35:50 UTC+1, Marc Bolós escribió:
    Dear,

    I've been using puppet for some time now. Usually when I have a problem I
    read all documentation refered to the problem I have.

    Recently I was trying to write a puppet erb template, that checks if host
    has one class defined, and if it has then writes some text to cron.

    After a lot of googleing, I found that the best way to do this was:

    <% if classes.include?( 'class1' ) -%>
    Some text
    <% end -%>

    And this worked.

    But when I try on the same erb file to look for other classes, then it
    only processes 1:
    <% if classes.include?( 'class1' ) -%>
    Some text
    <% end -%>
    <% if classes.include?( 'class2' ) -%>
    Blah Blah Blah
    <% end -%>

    I can find only "Some text" inside file. But this host has class2 also
    declared. If I remove if classes.include of class1, and leave alone class2
    text, then I can see the text of class2.

    Did anyone had this issue before?

    Thanks for your time.
    --
    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+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedFeb 14, '13 at 5:27p
activeFeb 26, '13 at 4:01p
posts17
users3
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase