Puppet users - Jul 2013 - Puppet 3.2 and Hiera: problem of order and tagged function

Hello everybody,

I''m testing Puppet 3.2 and Hiera (installed with
http://apt.puppetlabs.com)
on Debian Wheezy. Here is my "/etc/puppet/manifests/site.pp" file :

-------------------------------------------------------
stage { "one": }
stage { "two": }
Stage[''one''] -> Stage[''two'']
hiera_include(''classes'')
-------------------------------------------------------

Here is the "init.pp" file of my "one" module :

-------------------------------------------------------
class one  ($stage = "one") {

    notify {"Class one is done":
        message => "Class one is loaded."
    }

}
-------------------------------------------------------

And here is the "init.pp" file of my "two" module :

-------------------------------------------------------
class two ($stage = "two") {

    if tagged("one") {
        $var = "YES"
    }
    else {
        $var = "NO"
    }

    notify {"Class two is done":
        message => "The value of var is $var."
    }

}
-------------------------------------------------------

If I use this yaml file for my host :


-------------------------------------------------------
---
classes:
  - one
  - two
-------------------------------------------------------

then everything is ok ($var == "YES") :

-------------------------------------------------------
# puppet agent --test
Info: Retrieving plugin
Info: Caching catalog for shinken.domaine.priv
Info: Applying configuration version ''1373027591''
Notice: Class one is loaded.
Notice: /Stage[one]/One/Notify[Class one is done]/message: defined 
''message'' as ''Class one is loaded.''
Notice: The value of var is YES.
Notice: /Stage[two]/Two/Notify[Class two is done]/message: defined 
''message'' as ''The value of var is YES.''
Notice: Finished catalog run in 0.16 seconds
-------------------------------------------------------

*But* if I use this yaml file for my host (change the order):

-------------------------------------------------------
---
classes:
  - two
  - one
-------------------------------------------------------

then $var == "NO" :

-------------------------------------------------------
# puppet agent --test
Info: Retrieving plugin
Info: Caching catalog for shinken.domaine.priv
Info: Applying configuration version ''1373027591''
Notice: Class one is loaded.
Notice: /Stage[one]/One/Notify[Class one is done]/message: defined 
''message'' as ''Class one is loaded.''
Notice: The value of var is NO.
Notice: /Stage[two]/Two/Notify[Class two is done]/message: defined 
''message'' as ''The value of var is NO.''
Notice: Finished catalog run in 0.12 seconds
-------------------------------------------------------

Yet, with "Stage[''one''] ->
Stage[''two'']", the classed are loaded in the
good order.

1) Is it normal ?

2) I would like to have $var == "YES" whatever the order of classes in
the
yaml file. Is it possible ?

Thanks in advance.


--
François Lafont





-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

On 05.07.2013 14:53, francois.lafont.1978@gmail.com
wrote:
> Hello everybody,
> Yet, with "Stage[''one''] ->
Stage[''two'']", the classed are loaded in the
> good order.
>
> 1) Is it normal ?
Yes.
> 2) I would like to have $var == "YES" whatever the order of
classes in
> the yaml file. Is it possible ?
tagged() (and all other functions) are parse-order dependent. The stage 
definition only establishes an application order. The recommended way 
forward is to express the configuration dependency explicitly like so:

   class meta($one = true) {
     if $one {
       include one
     }

     class { ''two'': one => $one }
   }

or to directly integrate this into the class two. This depends on your 
actual use case.

Regards, David

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Le vendredi 5 juillet 2013 17:43:47 UTC+2, David Schmitt a écrit :
> 2) I would like to have $var == "YES" whatever the order of
classes in
> > the yaml file. Is it possible ? 
>
> tagged() (and all other functions) are parse-order dependent. The stage 
> definition only establishes an application order. 

Ok, thank you for the distinction between "parse-order" and
"application
order", I keep that in mnd. In these conditions, I think the
"tagged()"
function loosing interest.

 
> The recommended way 
> forward is to express the configuration dependency explicitly like so: 
>
>    class meta($one = true) { 
>      if $one {
>        include one 
>      }  
> or to directly integrate this into the class two. This depends on your 
> actual use case. 
>
Sorry, but I tried to understand your example but I didn''t. Do I have
to
put the "meta" class in the yaml file of my host? If yes, I
don''t see why
it solves the problem. Sorry. I''m a puppet beginner.

In fact, I''ll explain the purpose of my post. I have choose a simplied 
example.
I have a class named "monitoring" (but in my example it''s the
"two" class)
in which I want to define some variables according to some other classes 
are used or not by the host. I show you :

class monitoring {

   # if the host uses the http class $http = "http" else $http =
"NONE"

   # if the host uses the mysql class $mysql = "mysql" else $mysql =
"NONE"

   # etc.
}

I thought tagged() function will make the job but, as you explain me,
it''s
order-dependent. I''ll try to think about your example...


--
François Lafont

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Hi,

I''m sorry but I haven''t solved my problem yet. I
haven''t understood the
answer of David Schmitt. I use Puppet 3.2 and Hierra with yaml files for 
the "classes" assignment. I would like something like that :

class monitoring {

  if tagged(http) {
    $http = "OK"
  } else { 
  $http = "NO "
  }
  
  if tagged(mysql) {
    $mysql = "OK"
  } else { 
  $mysql = "NO "
  }

  # etc.
  # etc.
}

But, as I have been explained, tagged is parse-order dependent. Is it 
possible to have the same thing but witout parse-order dependency? Is there 
a function like tagged but no parse-order dependency?

--
François Lafont


-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

On Friday, July 5, 2013 12:20:55 PM UTC-5, francois.l...@gmail.com
wrote:
>
>
>  
>>
>> The recommended way 
>> forward is to express the configuration dependency explicitly like so: 
>>
>>    class meta($one = true) { 
>>      if $one {
>>        include one 
>>      }  
>> or to directly integrate this into the class two. This depends on your 
>> actual use case. 
>>
>
> Sorry, but I tried to understand your example but I didn''t. Do I
have to
> put the "meta" class in the yaml file of my host? If yes, I
don''t see why
> it solves the problem. Sorry. I''m a puppet beginner.
>

David inferred, as do I, that your intention is for class
''two'' to make
different declarations when class ''one'' is also declared for
the target
node than when it is not.  His idea was to use a separate class to manage 
the parse-time dependencies between class ''two'' and class
''one''.  David was
suggesting that instead of declaring those classes directly, you declare 
only class ''meta'', letting it take care of declaring the
others (or not).
A parameter of that class controls whether class ''one'' is
declared, and its
value is forwarded to class ''two'' (as a new parameter) to tell
that class
whether class ''one'' is declared.

The YAML is a secondary issue.  In fact, I''m surprised that
you''re doing
anything with YAML at such an early stage in your testing.  I suppose you 
are trying to use an external node classifier (ENC), but it might be better 
to start out with ordinary node declarations in site.pp until you get a 
better handle on how Puppet works.

 
>
> In fact, I''ll explain the purpose of my post. I have choose a
simplied
> example.
> I have a class named "monitoring" (but in my example
it''s the "two" class)
> in which I want to define some variables according to some other classes 
> are used or not by the host. I show you :
>
> class monitoring {
>
>    # if the host uses the http class $http = "http" else $http =
"NONE"
>
>    # if the host uses the mysql class $mysql = "mysql" else
$mysql = "NONE"
>
>    # etc.
> }
>
> I thought tagged() function will make the job but, as you explain me,
it''s
> order-dependent. I''ll try to think about your example...
>
>
There is a key difference between that and your original example, which 
makes a lot of difference: your ''monitoring'' class has
dependencies on a
bunch of different classes, rather than on only one.  You could still 
construct a solution along the lines of David''s suggestion, but under
these
circumstances I would suggest a different approach.

First, split up your ''monitoring'' class into several separate
classes: one
for the modeling framework and your general modeling requirements, and a 
separate class for each service you want to be able to monitor (e.g. 
monitoring::httpd, monitoring::mysql, etc.).  Perhaps you already have such 
a division.  Have each of the service-specific monitoring classes declare 
the main monitoring class; e.g.

class monitoring::httpd {
  include ''monitoring''
  # ...
}

Next, declare the service-specific monitoring classes explicitly.  If 
you''re doing it via an ENC, then it would look like this:

classes:
  - httpd
  - monitoring::httpd
  - mysql
  - monitoring::mysql

That has the added advantage that you can pick and choose which services 
are monitored.

If you want to reduce the number of separate classes declared then you can 
combine that with something along the lines of David''s suggestion. 
There
are several ways to do that, but I think I''d do it like this:

class site::httpd_monitored {
  include ''httpd''
  include ''monitoring::httpd''
}

class site::mysql_monitored {
  include ''mysql''
  include ''monitoring::mysql''
}

classes:
  - site::httpd_monitored
  - site::mysql_monitored

That reduces the number of classes to one per service, retains the ability 
to pick and choose what is monitored, and avoids introducing any direct 
dependency between the service modules (httpd and mysql) and the monitoring 
module.


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.
For more options, visit https://groups.google.com/groups/opt_out.