I have code similar to the following:
class someclass($ensure = installed)
{
if($ensure == installed)
{
$installValue = installed
file { "someprogram.msi":
ensure => file,
source => 'somewhere',
path => 'C:/puppet-files/someprogram.msi',
}
}
else
{
$installValue = absent
}
package{ "someprogram":
ensure => $installValue,
source => 'C:/puppet-files/someprogram.msi',
}
}
Does the if statement containing the file resource ensure that the file resource will get applied before the package resource? Or do I need to explicitly state this in the metaparameters? Also, I am assuming that the $installValue will always be set before the package is installed, is that correct?
Thank you,
Derongan
You should specify the ordering explicitly, however the variable will be initialised correctly.
The ordering of resources in Puppet 3 is deterministic, but essentially random as it's based on hashes of the resource titles. In Puppet 3.3, this behaviour can be changed to the manifest order (release notes), but I wouldn't recommend relying on this - certainly if you're sharing the module, there's no guarantee that others use the same setting.
Since the file resource may not exist (if ensure => absent), you can't specify the relationship on the package resource. Instead, add before => Package['someprogram'], to the file resource.
Related
I'm trying to set up a Puppet cron job with the following structure:
file { '/usr/local/sbin/file.py':
mode => '0755',
source => 'puppet:///modules/file.py',
require => File['/usr/local/sbin']
}
cron { "cronjob":
require => "ALL_THE_FILES_ABOVE"
command => "...command_to_run_script..."
minute => '*/1'
}
All of the above is in one file run_script.pp. I'm wondering how I can code the require => "ALL_THE_FILES_ABOVE" part.
Thanks!
Based on the information provided in your question, I am going to make the assumption that the contents of run_script.pp is many file resources and the listed cron resource. You state that you want the cron resource there to require all of the file resources in that class. Based on this, here is a clean and efficient solution.
There are a few complicated/advanced ways to arrive at a clean and efficient solution, but the easiest to understand is to use a resource default: https://puppet.com/docs/puppet/5.3/lang_defaults.html
With this, we can establish attribute/value pair defaults for all file resources contained in that scope. This would make it easier to use the before metaparameter on the file resources instead: https://puppet.com/docs/puppet/5.3/metaparameter.html#before
This simplifies the solution to a one-liner in your class:
File { before => Cron['cronjob'] }
Note there will be a caveat to this method, which is that if you are declaring, requiring, or containing a class within this manifest, then this default could be expanded to that "area of effect" and cause a circular dependency. In that case, you should use a per-expression resource default attribute: https://puppet.com/docs/puppet/5.3/lang_resources_advanced.html#per-expression-default-attributes
You can use a multiple require
file{'path/foo':}
file{'path/bar':}
file{'~/foobar':
require => [ File['path/foo'], File['path/bar'] ]
}
or you can use the ordering arrow
-> (ordering arrow; a hyphen and a greater-than sign) — Applies the resource on the left before the resource on the right.
file{'path/foo':} ->
file{'path/bar':} ->
file{'~/foobar':}
Here is more information about relationships and ordering in Puppet
I include the class nova::compute::libvirt and this class defines a Package resource like so:
package { 'libvirt-nwfilter':
ensure => present,
name => $::nova::params::libvirt_nwfilter_package_name,
before => Service['libvirt'],
tag => ['openstack', 'nova-support-package'],
}
The problem is that the RPM is in a YUM repo that is not enabled enabled=0.
I could solve this issue by changing nova::conpute::libvirt so that Package resource looked like this:
package { 'libvirt-nwfilter':
ensure => present,
name => $::nova::params::libvirt_nwfilter_package_name,
before => Service['libvirt'],
tag => ['openstack', 'nova-support-package'],
install_options => ['--enablerepo', 'redhat_updates'],
}
But I'd like to not have to modified a module I got from puppet forge because the next time someone else setups up a puppet master they might forget to make the modification. Is there something I can do from the class that includes nova::compute::libvirt?
Resource collectors afford the possibility of overriding attributes of resources declared elsewhere. The syntax would be:
Package<| title == 'libvirt-nwfilter' |> {
install_options => ['--enablerepo', 'redhat_updates']
}
That alternative avoids modifying the repository definition, and it does not require introducing any new ordering relationships. Beware, however, that collectors always realize any matching virtual resources. Beware also that this approach is very powerful, and thus very easy to abuse to get yourself in trouble. With great power comes great responsibility.
You can solve this problem by enabling the redhat_updates yum repo with a yumrepo resource, and then specifying a metaparameter for it to be applied before the class.
yumrepo { "redhat_updates":
baseurl => "baseurl",
descr => "Redhat Updates",
enabled => 1,
gpgcheck => 0,
before => Class['nova::compute::libvirt'],
}
https://docs.puppet.com/puppet/latest/types/yumrepo.html
Let us say that I have a case in which I need to apply only two files from a Puppet configuration on some production servers, without touching the rest of the configuration.
/opt/aservice/myfile/thekey.conf
/opt/myfile/thekey.salt
Let's also say that these are controlled by the following Puppet manifest:
#
# author: Nathan Basanese (nathan#basanese.com)
# date: 04/17/2048
#
class keyconfig ( $cluster ){
notify {"Deploying key config. files to $fqdn":}
file {'/opt/aservice/key/config/thekey.conf':
ensure => present,
mode => '0644',
owner => 'aservice-serv',
group => 'aservice-serv',
source => "puppet:///modules/keyconfig/$cluster/thekey.conf",
}
file {'/opt/aservice/key/config/thekey.salt':
ensure => present,
mode => '0644',
owner => 'aservice-serv',
group => 'aservice-serv',
source => "puppet:///modules/keyconfig/$cluster/thekey.salt",
}
}
How would I apply ONLY these two files to a given server from a Puppet Master?
Perhaps, in the puppet agent command that is run on the target server, could I specify a specific Puppet class to use?
I have used the puppet resource command before, but I'm not sure that would work, here.
Every resource is automatically tagged with the fully qualified name of the class or defined type in which it is declared, and with every namespace segment of the class or type name, among other tags. You can use those tags to filter the resources that will be applied during a given catalog run. In the particular example you describe, you could use
puppet agent --no-daemonize --onetime --tags keyconfig
to apply only the resources declared in class keyconfig (and in any other class declared by keyconfig, recursively, but in this case there are no such other classes).
You can also declare tags manually by using the tag metaparameter in your resource declarations. That can allow you to provide for identifying custom collections of resources. And speaking of collections, you can use tags in the selection predicates of resource collectors, too.
The only way to do that is to have that node contain only the class you are wanting to have applied. In your site.pp you would have the following where the 'myhost.dns' is your fqdn. and $mycluster would be replaced by your cluster string.
node 'myhost.dns' {
class { 'keyconfig':
cluster => $mycluster,
}
}
I have a service implemented in Java which depends on 3 property files. I have defined 'define' for each of the property file in a common properties module and consuming them from service specific module. The 'define' for one of the property file is shown below:
define properties::rabbitmq (
$property_file,
$service_name,
$rabbitmq_host,
$rabbitmq_username,
$rabbitmq_password,
$rabbitmq_port,
$rabbitmq_vhost) {
file { $property_file:
ensure => file,
content => template('config/rabbitmq.properties.erb'),
mode => '0644',
notify => Service[$service_name],
}
}
I am following roles and profile pattern in my puppet code and doing all hiera lookups in service specific profile. Now because of this whenever there is a change in property files, I need to make cascading changes to all of my puppet modules that consumes that property file. The changes are needed in profile (hiera lookup), module init.pp (addition/removal of parametes from constructor) and config.pp (parameter adjustment when invoking 'define' for a property file).
I feel that the above problem can be solved by incorporating hiera lookups in 'define' for a property file, like this:
define properties::rabbitmq ($property_file, $service_name,) {
$rabbitmq_host = hiera('rabbitmq_host')
$rabbitmq_username = hiera('rabbitmq_username')
$rabbitmq_password = hiera('rabbitmq_password')
$rabbitmq_port = hiera('rabbitmq_port')
$rabbitmq_vhost = hiera('rabbitmq_vhost')
file { $property_file:
ensure => file,
content => template('config/rabbitmq.properties.erb'),
mode => '0644',
notify => Service[$service_name],
}
}
But, above is a violation of roles and profile pattern. The above is doing hiera lookup in a module instead of doing it in profile. Now, the module has a tight dependency on hiera. It being an internal module (not meant for puppet forge), I guess, it should be OK to violate the guideline in favor of code maintainability.
I seek opinion from others on above.
I have encounter really weird behaviour which goes against what I have learned, tutorial says etc. So I would be glad if someone could explain why that is happening.
I have a role module which is made up of composition of profiles (role-profile pattern). My role consists:
class role::lab_prg_c2_dn inherits lab_prg_c2 {
class { 'profile::cluster_data_node':
namenode_fqdn => $role::lab_prg_c2::namenode_fqdn,
secondarynamenode_fqdn => $role::lab_prg_c2::secondarynamenode_fqdn,
}
->
class{'bigdatasolution':}
}
First class installs technology and second one installs our components and items which are build on top of technology. Hence the technology need to be installed first, thats the reason for "->" dependency. However this seems to me doesn't work correctly. As components from class 'bigdatasolution' are installed somewhere before the class profile::cluster_data_node finishes.
I tried to use require => Class['profile::cluster_data_node'] but that doesn't make any difference!
The content of class{'bigdatasolution':} :
class bigdatasolution {
$hdfs_default_conf = '/usr/local/hadoop.hdfs.conf'
$hbase_default_conf = '/usr/local/hadoop.hbase.conf'
include symlinks
include bdjar
}
Symlinks - create symlinks for the configuration installed in class profile::cluster_data_node and are not directly managed - it will be presented when actually specified package get installed.
bdjar - add our jar to a technology library so content is as follows:
class bigdatasolution::bdjar {
file { "/usr/lib/hadoop/lib/bigdata-properties.jar":
ensure => present,
mode => 0644,
group => 'root',
owner => 'root',
source => "puppet:///modules/bigdatasolution/bigdata-properties.jar"
}
}
I even tried to put require => "technologycalClass" here but that doesn't help either.
Can someone please help me understand what's wrong and how that should be solved properly?
I Using puppet 3 and ordering is specified explicetly - so no arbitrary ordering set by puppet should happen.
Thanks
If your 'profile::cluster_data_node' class 'includes' other classes/modules they will have no dependency ordering with the 'bigdatasolution' class.
I see you actually do include symlinks and bdjar. Basically every piece of ordering you want to have in puppet, you need to write explicitly.
Here you should replace the include statements with require, that way the class cluster_data_node will require the other two modules to complete before it says it has completed. Include is a pretty lose way of importing things in puppet and in my opinion is best to just avoid it and go with explicit require statements instead.
TL;DR: included modules have no transitive ordering; required modules do.