I was looking for a simple example of how to iterate through an array in a Puppet module. I basically needed an example of a “for loop” inside a Puppet module that I could, as someone who is not exactly fluent in Ruby, could modify to fit my needs.
I settled on the format that you see below.
The “define” code block is basically the work that we want the Puppet module to do. In this case, it’s create a file in /tmp. Think of this line as pretty much just a placeholder for more complex code.
The “class” code block is where we setup our array of items for the module to “loop” through.
[sourcecode language=”bash”]
#
#
# Test Module
#
#
This is going to be a very simple example of how to convert a variable to all lowercase inside a Puppet module.
If you look, which I am sure that you have already…there seems to be a lot of documentation around how to use the Ruby “downcase” function, but not much of it is easy to read if you are not very familiar with Ruby.
In this example, I create a very simple Puppet module and show how to use the downcase function.
[code language=”css”]
class test-module (
$myname = "TEST",
){
$myname_downcase = downcase($myname)
file { "/var/tmp/$myname_downcase":
ensure => present,
content => "This is a Test File for $myname_downcase",
}
}
[/code]
In this example I have a Variable called $myname. I am setting $myname to TEST inside the init.pp.
Note however you would probably never do this. More than likely you would do one of the following:
Set $myname so that it is an external environmental variable
Set $myname to NULL and override in Foreman.
The meat in this potato is this line here, where we take the $myname variable and munge it into a new variable called $myname_downcase.
In this instance we are trying to run Red Hat Cloudforms, also known as Manage IQ, and Puppet together on the same RHEL 6 host.
Our goal here is to push out some configuration to the Cloudforms appliances via Puppet. However we ran into issues as the version of Ruby/Ruby Gems used by Cloudforms is different than the version used by Puppet and they are stepping on each other a bit.
Here is the error we see when attempting to run Puppet
Interesting read for those who want to integrate Foreman into their RHEV environment. I’m still working on figuring out the exact benefits of doing so, but this this seems like its the go-to guide to reference.
This example will walk us through the process of adding a standalone Puppet host to Foreman for the purpose of managing the host through Puppet. In this instance we are going to create a standalone-hostgroup for the server.
Note that the Foreman server must be able listening on ports 8140, and 6163 (according to Puppet documentation). My RHEL7 Foreman host was listening on these ports, but the firewall was blocking any inbound connections. I corrected this with the commands shown below.
First I needed to determine my default firewalld zone.
# firewall-cmd –get-default-zone
Then I ran the commands below to punch a hole in the firewall to allow the required traffic. I also reloaded firewald.
Now we add an entry for the puppet server in /etc/puppet/puppet.conf in section [agent], where <PUPPETSERVER-FQDN> is the FQDN of your Foreman Server
server = <PUPPETSERVER-FQDN>
Now save the file.
Then on the Puppet client run the following command.
# puppet agent -t waitforcert 60
Log into Foreman WebUI. Navigate to => “Infrastructure” => “Smart Proxies” => “Certificates”
In the list located the new puppet client and click on sign to accept the key for the new host. The host that I am adding is osd01.lab.localdomain.
NOTE: Once you have accepted the key you need to run the puppet client again (puppet agent -t) on the client. Otherwise the client will not appear in on the “All hosts” page
Now Lets create a new Host Group to use for this server. Come on, its will be a blast.
Navigate to => “Configure” => “Host groups“. Select the green “New Host Group” button and then add your host group. Here I have added a host group called “Standalone Hosts”. See below.
Now we need to add our new client to this new host group. We do so by navigating to => “Hosts” => “All hosts“. Then select “Edit” to the left of the host.
Click “Submit” an the bottom of the page and you are good to go.
Sitting in my hotel room today, I kept running into this error while trying to install OpenStack on a RHEL 7.1 VM running on my laptop. Digging through logs was not helping me one bit, and neither was trying to run “puppet apply” on the failing puppet manifests to see if I could get more info with which to troubleshoot.
Below is the specific error that I was running into. Note that my RHEL VM’s IP address is 192.168.122.75. This IP address is pre-pended to the puppet module names. Your output, will obviously, vary. Note that this output is truncated.
ERROR : Error appeared during Puppet run: 192.168.122.75_amqp.pp
Error: Could not start Service[rabbitmq-server]: Execution of ‘/usr/bin/systemctl start rabbitmq-server’ returned 1: Job for rabbitmq-server.service failed. See ‘systemctl status rabbitmq-server.service’ and ‘journalctl -xn’ for details.
You will find full trace in log /var/tmp/packstack/20150415-183003-mn6Kfx/manifests/192.168.122.75_amqp.pp.log
Please check log file /var/tmp/packstack/20150415-183003-mn6Kfx/openstack-setup.log for more information
Additional information:
Each and every time, the failure occurred when the installer was trying to install/start and rabbitmq-server via the puppet module amqp.pp. Attempting to start rabbitmq manually yielded the same result.
In this instance, I was trying to be fancy and I had given my VM the hostname packstack01.local (instead of sticking with localhost).
Fresh out of any good ideas, I noticed that a simple nslookup on my made up hostname actually returned results. Results that I would not have expected to be valid.
Despite never referencing my made up hostname in my answer file (by default, the answer file is generated with IP addresses only) the Rabbitmq service was attempting to connect to itself via hostname, which obviously failed as this is a valid ip and since I was working in a hotel room without proper dns, my server was trying to connect to a machine on the opposite side of the country.
A quick bit of tinkering in the /etc/hosts file resolved this issue, and I was able to complete my install.
Note that there are probably many other reasons why one might run into this error during an OpenStack install via Packstack, however this is the one that I ran into, and thankfully it was easy to fix.
Note to self – always use localhost when working without a valid DNS entry.
