I'm not sure about tagging nodes versus tagging resources like a
class.   That all being said, I don't think the right modelling here
is to use tags to determine behavior.

Rather I'd have something like:

class autofs
class autofs::server inherits autofs
class autofs::laptop inherits autofs

and then in the node:

node foo {
    include autofs::server
}

That will be more manageable as you aren't relying on what are
essentially magic variables assigned to the node.
Tags are useful for when you want to evaluate just part of the
configuration, etc, such as tagging a class and running just the
security parts, but I wouldn't use them in this way.

On Wed, Apr 14, 2010 at 8:47 AM, Mark Nelson <m...@tardis.cx> wrote:
> Hello
>
> I am trying to use tags to differentiate between machines that are servers
> and machines that are clients.  I am using the tag statement within the node
> definition as shown below -
>
> node shadow inherits default
> {
>          tag("server")
> }
>
> The default node is defined as follows -
>
> node default
> {
>      include "root-ssh-key"
>      include "dns"
>      include "puppet"
>      include "sshd"
>      include "autofs"
> }
>
>
> Within the class definition I am testing to see if the machine has been
> tagged as a server and setting variables accordingly.
>
> class autofs
> {
>     if tagged(server)
>     {
>         $auto_master="puppet://puppet/files/common/etc/auto.master.server"
>         $auto_mt="puppet://puppet/files/common/etc/auto.master.server"
>         $auto_home="puppet://puppet/files/common/etc/auto.home.server"
>     }
>     else
>     {
>         $auto_master="puppet://puppet/files/common/etc/auto.master.laptop"
>         $auto_mt="puppet://puppet/files/common/etc/auto.master.laptop"
>     }
>
>     file
>     {
>         "/etc/auto.master":
>
>                 source  => $auto_master,
>                 owner   => "root",
>                 group   => "root",
>                 mode    => "444",
>                 notify  => Service["autofs"];
>     }
> }
>
> When I run puppetd --test -dv, the following error appears -
>
> err: //autofs/File[/etc/auto.master]: Failed to retrieve current state of
> resource: Could not retrieve information from source(s)
> puppet://puppet/files/common/etc/auto.master.laptop at
> /etc/puppet/manifests/classes/autofs.pp:32
>
> It appears that the if statement is failing.  Am I using the tag feature
> incorrectly?
>
> I am using the following software -
>
> Operating System:
>
> Scientific Linux SL release 5.3 (Boron), Scientific Linux is a rebuild of
> Redhat Enterprise
>
> Ruby version:
>
> ruby-shadow-1.4.1-7.el5.x86_64
> ruby-irb-1.8.5-5.el5_3.7.x86_64
> ruby-libs-1.8.5-5.el5_3.7.x86_64
> ruby-rdoc-1.8.5-5.el5_3.7.x86_64
> ruby-1.8.5-5.el5_3.7.x86_64
> ruby-augeas-0.3.0-1.el5.x86_64
> ruby-ldap-0.9.7-3.el5.x86_64
>
> Puppet Version:
>
> puppet-0.25.5-0.1.rc1.el5.noarch
> puppet-server-0.25.5-0.1.rc1.el5.noarch
>
> Any help gratefully received.
>
> Mark.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>

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

Reply via email to