Condition on class existence on agent

[zerozer...@gmail.com]

Hi,

how can I create a condition based on the presence of a specific puppet class on the host?

I'm using Foreman, some hosts have myclass_a applied, while others have myclass_a AND myclass_b.

Resources in myclass_b are applied after resources in myclass_a.

Both classes change a parameter inside a configuration file, using augeas. But this causes two changes in the file on each puppet run (from state b to a, and then from state a to b again).

So I'm trying to do something like this, to prevent myclass_a from applying the modification if also myclass_b is present:

class myname::myclass_a {

  if defined("myname::myclass_b") {

    $confchanges = [

                     'set anotherpath_b anothervalue_b', # if class B is present, I only apply my specific edits

                    ]

  }

  else {

    $confchanges = [

                     'set anotherpath_b anothervalue_b',

                     'set mypath myvalue_a', # if class B is absent, I also apply the conflicting edit

                    ]

  }

  augeas { 'myconffile_a':

    lens    => 'Puppet.lns',

    incl    => '/etc/myconf.conf',

    changes => $confchanges,

  }

}

class myname::myclass_b {

  augeas { 'myconffile_b':

    lens    => 'Puppet.lns',

    incl    => '/etc/myconf.conf',

    changes => 'set mypath myvalue_b',

  }

}

...but this does not work, it never gets to the "else" section. Probably because the "defined" function is evaluated on the puppet master, where the class always exists.

I cannot use a condition on the existence of the "myconffile_b" resource, because this is parse order dependent and would always return false when evaluated inside myclass_a.

Any suggestions?

I'm looking into alternatives like virtual resources or defined types, but I cannot see anything better suited at the moment.

Thanks.

Marco

[Nikola Petrov]

Hmm not sure what but there is something smelly here going on...

What is the reason for the definition of those classes on the same host?
Can't it just be a single class with a parameter moved to hiera or
something else? My other suggestion would be to create a fact that
changes the setting on the machine based on the fact value.

--
Nikola

> --
> 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...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/6d3c91d0-f70a-45dc-8dfe-d9309570425c%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[zerozer...@gmail.com]

On Wednesday, February 26, 2014 2:47:32 PM UTC+1, nikolavp wrote:

 

What is the reason for the definition of those classes on the same host?

That's because I have some more general "role A" to which some hosts belong, but I also have "role B" which is some sort of further specification of role A, and host B belongs to it and thus needs a more specific configuration file.

 

Can't it just be a single class with a parameter moved to hiera or

Er... I never used hiera until now.

I had a look at the doc but it seemed to me a bit overkill for this requirement.

something else? My other suggestion would be to create a fact that
changes the setting on the machine based on the fact value.

Would be a good idea, but can a fact be created with a value which depends on puppet classes assigned to the host?

Uhm... maybe assign the fact value based on the output of a command like "puppet resource user <someuser_created_only_on_host_b>"?

I'm afraid the result would be based on existence on the master again, not on the agent.

Thanks.

[Nikola Petrov]

On Wed, Feb 26, 2014 at 07:12:19AM -0800, zerozer...@gmail.com wrote:
> On Wednesday, February 26, 2014 2:47:32 PM UTC+1, nikolavp wrote:
>
>
> > What is the reason for the definition of those classes on the same host?
> >
>
> That's because I have some more general "role A" to which some hosts
> belong, but I also have "role B" which is some sort of further
> specification of role A, and host B belongs to it and thus needs a more
> specific configuration file.

A specific example I think will be of much help. Some ideas:

1) Is "role B" just a more specific "role A" or they aren't so much
related. You can use inheritance if they are and change the file/define
you are interested in. Although inheritance is almost always abused
in this setup it is OK.

>
>
> > Can't it just be a single class with a parameter moved to hiera or
>
>
> Er... I never used hiera until now.
> I had a look at the doc but it seemed to me a bit overkill for this
> requirement.

Other ways to do this would be to just "propagate" the parameter for the
change to both "role A" and "role B" with default values.

>
> something else? My other suggestion would be to create a fact that
> > changes the setting on the machine based on the fact value.
> >
>
> Would be a good idea, but can a fact be created with a value which depends
> on puppet classes assigned to the host?
> Uhm... maybe assign the fact value based on the output of a command like
> "puppet resource user <someuser_created_only_on_host_b>"?
> I'm afraid the result would be based on existence on the master again, not
> on the agent.
>

I am not sure if understood the idea. I am not saying that you have to
create a dependant fact but just to set a fact with the value you want
to change. So let's say you want to have a database connection URI. Role
A sets it to something by default and Role B sets it to something else.
You can specify the wanted connection URI on the host with custom fact.

N.B. Can you also tell us how do you assign the roles for each host
because that might help us be more specific with a solution.

--
Nikola

[zerozer...@gmail.com]

On Thursday, February 27, 2014 8:52:04 AM UTC+1, nikolavp wrote:

A specific example I think will be of much help. Some ideas:

1) Is "role B" just a more specific "role A" or they aren't so much
related. You can use inheritance if they are and change the file/define

Yes, B is some sort of "more specific A".

Not easy to explain because they use custom apps, services, and files (and I don't even fully know how they work), but maybe this example will fit:

• role A is "web server"
• role B is "secure web server"
• the same set of resources (packages, users, files, configuration edits...) is applied for both roles, but role A sets some permissions in httpd.conf while role B needs more strict permissions for the same web paths, so they need to use different parameters for the same line in the same file.

Maybe inheritance is the way to go?

I can put my resource (and related ones) in a separate class with a parameter for the value to be inserted in the conf file, and then create two different classes for roles A and B which inherit the class and override the resource attribute through the parameter.

Is that right?

Other ways to do this would be to just "propagate" the parameter for the
change to both "role A" and "role B" with default values.

What do you mean?

 

I am not sure if understood the idea. I am not saying that you have to
create a dependant fact but just to set a fact with the value you want
to change. So let's say you want to have a database connection URI. Role
A sets it to something by default and Role B sets it to something else.
You can specify the wanted connection URI on the host with custom fact.

Ok, but how can I create this custom fact on the hosts?

I'm provisioning the hosts through Foreman, I need the installation and configuration of the hosts to be automated, based on the classes/roles selected in the Foreman GUI. I do not want to create the custom fact "by hand" on each host.

That's why I was thinking about checking the classes applied to the host, as a way to automatically detect the value to be assigned to the fact.

 

N.B. Can you also tell us how do you assign the roles for each host
because that might help us be more specific with a solution. 

I assign puppet classes to the hosts using the Foreman web GUI; either specific classes during tests, or by associating the classes to different host groups and then assigning hosts to groups.

Thank you very much.

Marco

[Nikola Petrov]

On Thu, Feb 27, 2014 at 03:12:53AM -0800, zerozer...@gmail.com wrote:
> On Thursday, February 27, 2014 8:52:04 AM UTC+1, nikolavp wrote:
>
> A specific example I think will be of much help. Some ideas:
> >
> > 1) Is "role B" just a more specific "role A" or they aren't so much
> > related. You can use inheritance if they are and change the file/define
>
>
> Yes, B is some sort of "more specific A".
> Not easy to explain because they use custom apps, services, and files (and
> I don't even fully know how they work), but maybe this example will fit:
>

> - role A is "web server"
> - role B is "secure web server"
> - the same set of resources (packages, users, files, configuration

> edits...) is applied for both roles, but role A sets some permissions in
> httpd.conf while role B needs more strict permissions for the same web
> paths, so they need to use different parameters for the same line in the
> same file.
>
> Maybe inheritance is the way to go?
> I can put my resource (and related ones) in a separate class with a
> parameter for the value to be inserted in the conf file, and then create
> two different classes for roles A and B which inherit the class and
> override the resource attribute through the parameter.
> Is that right?

With inheritance you get the following:

class webA {
...
file { '/etc/myapp/config.properties':
content => template('my-default-template')
....
}
...
}

class webB inherits webA {
File['/etc/myapp/config.properties'] { # note the capital File and the same resource name as above
content => template('my-custom-template'),
}
}

More can be found in
http://docs.puppetlabs.com/puppet/latest/reference/lang_classes.html#inheritance
look at the "Overriding Resource Attributes" section. Although I don't
like inheritance as you describe it if roleB is a secure web server and
roleA is a web server I would go for it.

>
> Other ways to do this would be to just "propagate" the parameter for the
> > change to both "role A" and "role B" with default values.
> >
>
> What do you mean?

Something like

class webA (
port = '8080' # this is the default
) {
...
}


class webB (
port = '8081' # this is the default
) {
...
}

now at this point if you want to declare them both you just use another
definition...

class mynewrole {
class { 'webA':
port => '8081',
}

class { 'webB':
port => '8081',
}
}

sadly this way the augeas or the way you do the change will be fired two
times :(

>
>
> > I am not sure if understood the idea. I am not saying that you have to
> > create a dependant fact but just to set a fact with the value you want
> > to change. So let's say you want to have a database connection URI. Role
> > A sets it to something by default and Role B sets it to something else.
> > You can specify the wanted connection URI on the host with custom fact.
> >
>
> Ok, but how can I create this custom fact on the hosts?
> I'm provisioning the hosts through Foreman, I need the installation and
> configuration of the hosts to be automated, based on the classes/roles
> selected in the Foreman GUI. I do not want to create the custom fact "by
> hand" on each host.
> That's why I was thinking about checking the classes applied to the host,
> as a way to automatically detect the value to be assigned to the fact.

Ok so the fact is not an option ;)

>
>
> > N.B. Can you also tell us how do you assign the roles for each host
> > because that might help us be more specific with a solution.
>
>
> I assign puppet classes to the hosts using the Foreman web GUI; either
> specific classes during tests, or by associating the classes to different
> host groups and then assigning hosts to groups.
>
> Thank you very much.
> Marco

--
Nikola

[zerozer...@gmail.com]

On Thursday, February 27, 2014 5:16:43 PM UTC+1, nikolavp wrote:

More can be found in
http://docs.puppetlabs.com/puppet/latest/reference/lang_classes.html#inheritance
look at the "Overriding Resource Attributes" section. Although I don't
like inheritance as you describe it if roleB is a secure web server and
roleA is a web server I would go for it.

Indeed, I was playing around with inheritance in the meantime and it solved my problem.

Even though at first I didn't read that Puppet 3 does not support parameters in the base class and this confused me quite a bit ;).

Thanks!