Puppet users - Feb 2013 - .erb templates are not properly parsed.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.