mark sparhawk
Hi Mark, This is related to the post you updated for the "build-pipeline-plugin-broken". If I down grade to 1.3.3 from 1.3.5, How do I use the build pipeline plugin 1.3.3 to carry parameters to the downstream jobs.

I have each of my jobs in a pipeline catch the parameter(s), and pass them on to the next job as predefined parameters using the Jenkins Parameterized Trigger plugin, regardless of whether or not the parameter is used in a given job.

Most of my jobs are Freestyle projects, or Maven 2/3 projects. I like to add a shell step to each of the jobs to run “export” so I can inspect what variables are being passed around.

Build Pipeline Plugin Broken

Looks like v1.3.5 of the Jenkins Build Pipeline Plugin is broken. Retried pipeline steps don’t include upstream parameters, which makes the pipeline nearly useless. The git commit messages suggest they are trying to refactor the retry functionality to disable retires on successful steps, I’m not sure I agree that this is necessary, but someone is working on it and this seems to be an unintended consequence.

Anyway, it’s impossible to revert in the GUI so you have to drop down to the shell and install the old version manually. Here’s my revert process:

*NOTE* You will have to reselect the initial pipeline job for each pipe after you revert, after the restart all of the pipelines will be there, but they will be empty.

cd /var/lib/jenkins/plugins/

rm build-pipeline-plugin.jpi

wget http://updates.jenkins-ci.org/download/plugins/build-pipeline-plugin/1.3.3/build-pipeline-plugin.hpi

service jenkins restart

Puppet - Part II

The folks over at puppet resolved their issues with the puppet 2.8.0 and I was able to get enterprise up and running. I grabbed their packages, shoved them into my yum repository and went about the task of deploying it to clients, and setting up some manifests on the server. 

The first thing I noticed was that I didn’t feel like I was bootstrapping puppet, I was more running scripts, and providing answer files. I put this into my kickstart, but this felt anything but the puppet way of doing things. 

But life is about new experiences, so I rolled this out to the rest of my sprawling home cluster of 7 nodes. At work I use a push strategy in conjunction with mcollective to drive deployment of changes. But PE just kind of out of the box starts auto pulling updates.

The Puppet Dashboard is very pretty. It shows all the runs for a day, how many of them resulted in changes, and how many had no changes. It’s nice to see configuration drift disappear in front of your eyes. One issue I had was a module I downloaded from Puppet Forge had a “notice” in it, and this was marked as a change with every run, even though no changes were implemented. 

I’m still not certain of the Puppet Enterprise value proposition, so my next project is to roll out OSS Puppet 3.2

Puppet 2.8.0 pulled for bug

I was hoping to have some notes from my puppet enterprise experience by now. But the process has been a bit frustrating. I’ve been running open source puppet since 0.24, and decided to give puppet enterprise a whirl, I quickly ran into some issues getting puppet enterprise up and running on my network. Today I recieved the following email:

We’ve found an issue in Puppet Enterprise 2.8.0 that keeps live management from functioning and prevents MCollective from using filters.

We have prepared a partial upgrade package that fully resolves this issue. If you have installed 2.8.0, you candownload the package fix here.

We have also temporarily pulled PE 2.8.0 from ourdownload page, and plan to release a fixed PE 2.8.1 sometime next week. We will notify you about the availability of PE 2.8.1 when it is released.

I’m not sure this explains all the issues I’ve had with puppet enterprise, but I’m putting this project on hiatus until they release 2.8.1

ROBOTS OR DINOSAURS?

ROBOTS!

Love this track, it has this great generational mashup feel. 

KVM Sprawl & Puppet Enterprise @home

My 12 months on Amazon’s free tier has expired so I decided to build a small VM implementation at home. The free tier is great for getting familiar with the Amazon offering, but if you want more than one node, or anything resembling a fast vm, it’s the wrong choice. 

I settled on CentOS + KVM as it works out of the box, and it’s the distro I prefer these days. I’ve set up a half dozen guests for various projects, and I’m already annoyed with the challenges of keeping these nodes in sync. 

This is where Puppet Enterprise comes in. I use puppet open source quite a bit at work, we’ve been looking at the enterprise edition ever since they launched it at puppet conf a few years back, but we haven’t pulled the trigger on a purchase.

Puppet Enterprise has a 10 node test drive license, available here: http://info.puppetlabs.com/download-pe.html. Sounds just about perfect for my little home lab, so at the end of the day I may wind up with a more robust puppet implementation at home then at work. 

CentOS + GCJ = Pain and Suffering

So far, the first two java applications I’ve installed have been unhappy with CentOS’s default java installation. 

After spending a few moments trying to fire up Jenkins, a quick trip to the support forum listed quite a few complaints, and one quick fix: Remove GCJ

Same issue with my Hadoop installation. Please use the Sun JDK. Why in the heck are the RedHat folks pushing this JVM? Hadoop was kind enough to turn me on to a more elegant solution: 

# alternatives --install /usr/bin/java java /usr/java/latest/bin/java 3
# alternatives --config java