PuppetCamp

Successfully Deployed!

PuppetCamp was solid. This page will transform into a collection of the artifacts puppetcamp generated.

There are videos already posted of the set talks. (that is an RSS feed, the second post of the second day won’t work, should be removed soon… high speed connections get video and slides, low speed get the audio)

The open sessions were super intense and engaging. They were also nearly impossible to capture without considerable AV infrastructure, especially the audio. I think some of the photos from these sets capture the spirit: Gary Larizza’s and Mike Halligan’s.

James Turnbull put some of his thoughts up on his blog.

The good bits eclipsed the minor logistical glitches and inconveniences. We’ll take any feedback we can to make sure 2.0 is better.

Thanks to Google, Rails Machine, SFSU, Beth Raby, Gwen Blanton and anyone else who helped make it happen!

On the Agenda

There will be plenty of Puppet Tips, Tips and Best Practices, and that’s just in the breaks and meals. Come hear about some of the most advanced Puppet implementations and the lessons learned along the way.

Learn:

  • How people are managing 1000s of machines across multiple data centers
  • Puppet development lifecycle
  • Test Driven System Information
  • Stored Configs

Share:
Open Space sessions are a great way to share and explore any ideas you might have about Puppet and systems management. (Imagine the good conference conversations that usually occur in the hallway, and make those an explicit part of the program.)

Schedule

10/1/2009
8:30:00 breakfast/checkin
9:00:00 welcome
9:30:00 Luke Kanies – Reductive Labs

Puppet – Past, Present and Future

A Puppet journey with the man who had the vision and made it all happen.

10:30:00 Ohad Levy – Infineon

How Puppet helped us to standardize, communicate and work together

Where we were coming from, which problems puppet solved and which new problems puppet introduced and how we solved them. (we have at least 15 different data centers, with thousands of servers)

How to manage a large repo with many puppet admins
How important is it to automate your puppetmasters as well
How to coordinate when changes are actually pushed to the clients

Why we built Gini, and how those ideas became Foreman.

11:30:00 James Turnbull – Puppet Release Manager

Developing for Puppet

- – Setting up a development environment
- – Workflow and Lifecycle – the birth and death of a patch
- – Git (or why Subversion sucks)
- – Why we won’t take your patch without tests AKA an introduction to
Tests and Testing
- – Fun with Redmine
- – Continuous Integration and you

12:30:00 Lunch
1:30:00 Introduce Open Space Technology
2:00:00 Open Space Session
3:00:00 Open Space Session
4:00:00 Break
4:30:00 Open Space Session
5:30:00 Open Space Reports
6:00:00 Reception
7:00:00 Dinner
10/2/2009
8:30:00 breakfast
9:00:00 welcome
9:30:00 Brice Figureau – Days of Wonder

All about storeconfigs

Storeconfigs is not a popular feature among Puppet admins, because most don’t know how to use it or fear performance issues. Attend this talk to know how to enhance your Puppet deployments with easy cross-nodes interactions and collaborations, while conserving system efficiency.

10:30:00 Paul Nasrat – Guardian and Facter Release Manager

Test-Driven Systems Information with Facter

Covering the existing facter code base, an introduction to test-driven development in Ruby using rspec. Covering why we need tests, issues that not testing in facter have caused, retrofitting tests and moving to test-first fact writing.

11:30:00 Deepak Giridharagopal -Dell MessageOne

Take Back the Stack

Sophisticated software often requires sophisticated infrastructure. Dell/MessageOne’s products are hosted on many, many machines, and we need high-level tools that let our developers leverage all that hardware while simultaneously simplifying management and deployment.

I will discuss how Dell/MessageOne uses puppet to tackle this problem at a high-level. Rather than producing a tarball of code, we produce tarballs of puppet modules that we deploy to our infrastructure using a generic, puppet-based deployment engine; puppet is deeply integrated into our product. This makes it easy to bring up new clusters for dev/qa/production, and it lets us program/refactor our infrastructure in a way that was previously excruciatingly difficult.

- Organizationally, who does what? Who writes the puppet code, and who
rolls it out? What works?

- What puppet modules did we end up using all over the place?

- How do we puppet-update thousands of machines as quickly as possible
without cratering our puppetmasters? (speed is important)

- How do we orchestrate puppet-based rollouts to all our machines in a
way that is maximally parallel, yet still allow explicit sequencing?

12:30:00 Lunch
1:30:00 Add new Open Space Topics
2:00:00 Open Space Session
3:00:00 Open Space Session
4:00:00 Break
4:30:00 Open Space Session
5:30:00 Reports and Closing Remarks

At the very least, you should come away well fed and with a stylish T-shirt.

Sponsors

Google it

Google them

Want to deploy, manage, support, monitor, and scale Rails? Done.

Want to deploy, manage, support, monitor, and scale Rails? Done.

Who Was There?

infineon digg Days of Wonder
clickability dell-messageone guardian.co.uk
Netomata proofpoint NYSE Euronext
Oracle Lab 42 DNS Works