3 classroom courses, 2 certifications, 1 foray into online learning = over 3,000 people trained

The Puppet Education and Certification department recently turned one year old, and it has been a productive first year with great new programs and curriculum yet to come. As a company, Puppet Labs has always focused on providing verifiably useful solutions, and Puppet Education and Certification is no exception.

For system administrators, we offer a Puppet Fundamentals for System Administrators course that allows students to spend three days exploring best practices in automating the configuration and administration of system infrastructure using Puppet. This introductory course covers topics such as the puppet agent-master architecture of Puppet, how to define and declare puppet resources, and how to make the most of modules already freely available through the Puppet Forge. Students who want to validate their hands-on experience with Puppet software can take the System Administration Using Puppet (Puppet 201) exam to earn their Puppet Professional certification.

For more experienced Puppet users, we offer the “Advanced Puppet for Puppet Masters”, a follow-on, three-day course to Puppet Fundamentals. This advanced course delves further into topics of advanced puppet resources, and adds considerations such as data separation and code compression, MCollective and PuppetDB, and deploying and scaling Puppet in complex environments. There is currently no exams for a Puppet Master certification to follow this course, but we might add one later, based on community demand.

Additionally, we offer an advanced, four-day training created specifically for developers called Extending Puppet using Ruby, preceded by an optional Introduction to Ruby for Puppet Development course. This course trains developers on developing and implementing custom facts, functions, and types and providers for Puppet. It also covers the development of custom plug-ins for MCollective, as well as custom reports for the entire Puppet solution. For developers who want to validate their skills, we offer a follow-up exam to this education track — the Puppet 301 exam Developing for Puppet using Ruby, which will bestow the Puppet Developer certification upon passing.

How effective are these trainings and certifications? Well, if course surveys are any indication, satisfaction is consistently high with overall satisfaction score averaging around 4.5 out of 5, applicability of the knowledge averaging around 4.65 out of 5, and instructor knowledge averaging around 4.8 out of 5. Of course, each student’s needs are unique, so come to one of our training courses and be sure to let us know your own rating for our Puppet Education and Certification offerings.

What’s next for Puppet Education and Certification? As indicated in our headline, we are busy working on making online learning available through a new Learning Management System on the Puppet Labs website, and our first sample course “What is Puppet” is available online right now to give you a taste of online learning to come. If you are looking for a tool to get others excited about Puppet, be sure to point them to this introductory video segment.

There are a number of offerings we are also considering, including task-based courseware on topics such as best practices through optimized Puppet modules, advanced concept lessons through our online courses, virtual delivery of our courses for remote attendees, and an expansion of our certification offerings. We would love to hear from our Puppet community members on what you would like to see, so please send us your inputs and requests to help us develop future offerings.

Have ideas and suggestions? Please send them to education@puppetlabs.com and make your input count.

Learn More

• New to Puppet? Check out this video for a very basic introduction
• Learn about the different types of training courses we offer
• Think you know Puppet? Well, get certified to prove your skills!

Sydney really blew away my expectations last week. Our local Puppet friends in Sydney were great and always willing to show us around the beautiful sites. I was also lucky enough to be there on Australia day, which concluded with the most amazing fireworks show I’ve even seen before at Darling Harbour.

To top it all off, the turnout at Puppet Camp Sydney was amazing. I kicked things off with a Puppet Labs “state of the union” talk, which was followed by a good architectural and functional overview of CloudStack, as well as a discussion of how to integrate it with Puppet by Joe Brockmeier from Citrix.

Stephen Wallace from ICE was next with a beginners talk on Puppet that covered the motivation for using Puppet and provided an overview of the tooling in its ecosystem. You can check out his slides on “Puppet for Sysadmins.”

Jamie Wilkinson from Google provided a presentation on monitoring that provided analysis of a time-series-database as an alternative to alerts. He focused on strategies for analyzing stored monitoring data that actually used calculus and derivatives! It inspired the math-nerd inside of me, and made me realize that monitoring could be fun.

NBN was gracious enough to provide two great presentations at Puppet Camp. The slides from Chris Fegan’s presentation on “The NBN Puppet Journey” are also available. Christopher Fegan discussed NBN’s experiences with Puppet, focusing on the tooling required to use Puppet to manage infrastructure changes as a part of a release process. Andrew Myers provided a presentation on their usage of MCollective that focused on use cases and security and use cases.

Gordon Rowell from Google presented on their usage of Puppet to manage the internal IT infrastructure at Google. His presentation focused on specific issues at Google related to scale and the nature of their distributed environments, and you can check out the slides on “Puppet at Google.”

Lindsay Holmwood gave an emotional performance that explained the events that lead to the disaster of Air France 447, with an emphasis on how its lessons can be applied to handling infrastructure failures. It was an extremely engaging presentation that captivated the audience.

Sina Sadeghi from Aptira discussed the OpenStack based platform being built by Aptira and detailed their usage of Puppet.

Thank you to everyone who attended or participated in the event! If you missed it, you can get links to the presentations for this event or materials from other past Puppet Camps by visiting the Previous Puppet Camps section of the Puppet Camp page.

Learn more:

• We have Puppet Camps coming up in Ghent, Stockholm, Oslo, Melbourne, Los Angeles, Italy, Chicago, Barcelona, Atlanta, Baltimore, London and Amsterdam. Visit the Puppet Camp page to register to attend or learn more about submitting talks.
• Attend PuppetConf, our annual operations conference held in San Francisco. You can sign up for a reminder when PuppetConf 2013 registration opens.
• Find a local Puppet User Group or start one in your city!
• Join the Puppet community.

The Problem

The National Broadband Network (NBN Co) is an Australian govern­ment owned enterprise formed in 2009 to build a broadband network which will provide a fiber-optic connection to 93% of Australian homes and businesses, with fixed wireless and satellite services to the remainder. After its creation, the NBN quickly needed to establish a public website in order to disseminate information, and to create a set of business services to allow partners to begin the process of requesting access to the new network. The internal development teams used a combination of bespoke application development, service development, and configuration of commercial off-the-shelf software to provide these services.

Because the NBN was in such a rapid startup mode, the infrastructure necessary to support the development of these websites and services was being created as the development proceeded. In development and test environments, projects could request new nodes and then manage them as they saw fit. In production-like environments, there were a limited number of available nodes that needed to be shared between multiple projects. However, each project focused only on their own infrastructure requirements and issues started to appear. For example:

• Two teams sharing infrastructure would make incompatible changes and only one team’s application would work.
• Nodes were being set up by hand, and changes that were made in development environments to resolve defects were not being applied to later environments, leading to regressions.
• No one had a good idea of what was actually on each machine or who owned it, leading to anxiety about deployments, configuration changes and the ability to audit IT systems effectively.
• Because each node was being created by hand by different individuals, the loss of a node required a considerable amount of work to recover.

A group of developers got together to work on resolving these problems. They set out to accomplish a few goals:

1. Stand up production and production-like test systems quickly from scratch.
2. Capture all the configuration information in version control so that machines could be provisioned quickly without manual intervention.
3. Have a single source of truth to determine what a node should look like so changes and their impacts could be analyzed prior to making them.
4. Integrate infrastructure as early as possible. If four teams were going to share a node in production, make them share nodes in test environments as well.
5. Make infrastructure changes using the same process as application changes—in particular, applying them in test environments so that their impact can be understood before they are applied to production.

Initial Implementation

The first implementation that was built started to address some of these goals, but when we came to use it we discovered several problems that needed to be fixed. Some of these issues are discussed in Figure 1, which presents this initial implementation, below.

The initial setup was as follows:

• Puppet was installed on all new servers being provisioned and setup to run in the out of the box configuration—it would poll for configuration changes at 30 minute intervals.
• Puppet usage across all development teams was inconsistent. Some teams had their server setup fully automated, some were partially automated, and some were hand-created masterpieces.
• The Puppetmaster daemons were set up manually.
• Each environment had its own repository, and migration of infrastructure code between environments was done manually.

This implementation lead to the following issues:

• The process to make infrastructure changes ended up being “Check in changes, log on to target server, manually trigger Puppet”
• Since changes were migrated manually between environments, not all changes would get migrated. This led to inconsistencies between environments and configuration drift.
• Environment-specific code bases lead to massive duplication in manifests and modules.
• Lack of automated processes for migrating code and inconsistent implementation of automation across all servers lead to frequent breakages and reduced trust in the infrastructure deployment.

Fixing the issues: Implementing a Deployment Pipeline for Infrastructure

As a result of these problems, a dedicated DevOps team was formed. The purpose of this team was to help development teams automate their server setup and configuration, and to create a better and more reliable process for migrating infrastructure code up to production environments.

By this stage, most teams had implemented a deployment pipeline to move their code from development to production, using a number of different technologies (Capistrano, Maven etc). The DevOps team decided to implement the same pattern for the infrastructure code, and chose to standardise on MCollective to roll out changes to nodes, Puppet for performing the migrations, and Go to manage the deployment pipeline. The aim was to be able to check a change into version control once, and then be able to promote it through test environments and finally into production at the click of a button.

The implementation of this pipeline consisted of the following steps as outlined in diagram 2 below:

1. “Unit testing” of infrastructure code
   • RSpec tests against custom Puppet/MCollective code.
   • Local compilation of all node manifests using the Puppet API.
   • Execution of a system wide Puppet ‘dry-run’ to catch errors and create a report detailing expected changes when applying that revision of the infrastructure code.
2. Promoting successful changes up to the next environments
• Instead of packaging up and promoting the entire infrastructure codebase, we simply promoted version control revision numbers through the deployment pipeline.
• When a new revision was migrated to the next environment, we used MCollective to tell the Puppetmaster to update its repository to the specified revision, which was taken from the previous successful run of the upstream environment.
3. Update environment using the specified configuration
   • Where before we had Puppet running in daemon mode on a 30 minute loop, we now wanted to have Puppet trigger only when the upstream pipelines had succeeded, or when manually requested by a user.
   • We implemented an MCollective agent to allow a command to be sent to all the machines in an environment to cause them to execute a Puppet update.
4. Post-update smoke tests
   • To ensure that the update of the infrastructure code was working as expected, we wrote a limited number of smoke tests to quickly ascertain whether all the expected applications on the nodes were running.
5. Publish packaged configuration information and update CMDB
   • Provided that the update and smoke tests succeeded on all nodes in the environment, the revision in version control would be made available to update the next environment.
   • In addition, each node would also write out a report to a CMDB detailing its current Puppet manifest.

This implementation has several important benefits:

• RSpec tests and local compilation could both be run on a developer’s machine prior to committing code. This enabled much faster feedback for developers so they could quickly catch issues such as syntax errors, cyclical dependencies and missing files.
• Code only had to be checked in once, and then could be migrated all the way to production with a click of a button. If we required a major production fix, we could push it through all stages of the pipeline from development to production in about 20 minutes.
• The output from the dry-run in the first phase of the pipeline provided a detailed report as to what would be changed on each node. This report was used by both developers and the Software Change Control Board to understand the impact of the changes that were going to go into production.
• The use of MCollective to trigger Puppet updates meant that we had complete control over when a particular revision was pushed into a new environment.
• Repeatability and consistency of infrastructure code deployments were much improved. Developers had confidence that what was getting pushed to production was the same baseline that had been tested extensively in pre-production environments. If necessary, we could re-deploy the same revision to an environment and have confidence that the results would be same: infrastructure deployment was idempotent.

There were also some limitations to this model:

• Because Puppet is additive only, there was no ability to revert changes as you would in a typical application deployment. If a change needs to be backed out, you must explicitly add configuration to reverse it, check this configuration in, and promote it to production using the pipeline. This meant that if a breaking change did get deployed into production, typically a manual fix was applied, with the proper fix checked into version control subsequently.
• Certain types of configuration are node-specific and could only be really tested when applied to the environment in which the node resided. We mitigated this risk as much as possible by using Vagrant to stand up virtual clusters on development machines, but these were never exact simulacra of the production environment, so bugs would very occasionally get through.
• Because the dry run report was the first step in promoting a change, it could be hard to dig out this report to determine the impact of a given revision to an environment when the promotion happened potentially days later. One possible solution would have been to implement the dry run report as the last stage in the previous environment’s build steps.

Conclusion

Storing configuration information in version control and using a tool like Puppet to apply infrastructure changes to your environments is a good first step to getting your infrastructure under control. Unfortunately, it is only the first step. In the same way that a business would never check in a change to a codebase and push it directly to production, operation teams need to be aware that simply adding Puppet as an entry point for changes is not enough to ensure success. A poorly-designed infrastructure change applied directly to production via Puppet is just as likely to cause an outage as a manual change made directly on the node.

The deployment pipeline model for software provides a path to production for every code change checked in by a developer. It implements a series of tests and verifications which the change must pass through to ensure that it is ready to go live. The benefit of this setup is that, provided the code change passes all the verifications, the team and the business both have confidence that changes can safely be made to production at any time.

Applying this same pattern to infrastructure changes allowed us to realize the same benefits. Since we had a single path to production, the only way a change could be applied to production was to have it applied and tested in each and every prior environment. In order to verify changes, we ensured that the infrastructure required for a project to run in production was also available in testing environments. Project-specific infrastructure changes could therefore be tested and promoted up to production alongside the application changes that required them.

The pipeline management tool we used—Go—provided both automated and manual configuration for promoting changes between environments. For testing environments, changes were automatically applied after check-in once the unit tests had passed. For controlled environments, changes that had made it through test environments could be promoted on demand. Finally, because our pipeline also produced a report of what it had done, we were able to detect uncontrolled changes and find out which well-meaning developer had been monkeying with an environment manually. This helped us to catch most uncontrolled changes and get them into version control to ensure they would be applied and promoted using our standard, controlled process.

Ultimately our infrastructure deployment pipeline gave us the ability to push changes to production on demand with a very high confidence that the change would work as expected. Reports were produced detailing what changes would take place on which nodes, and then the changes were verified using smoke tests. The teams became so confident that it was not unexpected to see changes being applied to production in the middle of the day. The combination of MCollective, Puppet, Go and the deployment pipeline pattern has enabled NBN Co to treat their infrastructure in the same way they treat any project. A project that can deliver specific requirements on time in a reliable, automated, and repeatable fashion.

Learn More:

• Take the 2012 DevOps survey
• Read other posts in the DevOps December series
• Go from ThoughtWorks Studios
• Deployment pipelines
• Continuous Delivery
• NBN Co

About the authors:

Andrew Cunningham has just joined Telstra as a Senior Middleware Engineer after spending 7 years with ThoughtWorks in Canada, USA and Australia. He has worked in a mixture of QA, development and operation roles for a wide variety of industries and projects. He has been focusing on DevOps work for the last three years since discovering that he could play as a systems administrator while still getting to write code.

• Twitter: @oldNoakes

• Personal blog: http://workblog.intothenevernever.com/

• Github: http://github.com/oldnoakes

Andrew Myers joined NBN Co in 2011 to play a part in building a high speed broadband network for all Australians. There he helped grow what was initially a small DevOps experiment, into it’s current state where the automation capabilities he helped design and implement are depended on by multiple teams every day. Preivously he’s worked as a software developer, experiencing the “old ways” first hand, as well as working on the other side of the fence providing technical support for development and collaboration tools. Andrew’s passionate about DevOps because it allows him to combine software development and system administration skills and be involved across the whole software development lifecycle.

The International Securities Exchange (ISE), a leading US options exchange, has just completed the first phase of its Puppet Enterprise deployment. For a company exceeding trading volumes of 2.5 million contracts per DAY, the decision to ‘puppetize’ their infrastructure not at random — it was carefully determined and deliberate.

Trevor Pott, reporter from The Register, talked with Rob Cornish of ISE to find out why ISE chose Puppet Enterprise, and how they’ve benefited from the software implementation.

“Talking to Rob Cornish – Technology Strategy and Operations Officer at ISE – and some of his team, the biggest thing that jumped out at me was the use of the past tense in describing a separation between his Linux and Windows IT teams. Cornish was eager to talk about both the operational time savings and the new version deployment time savings the organisation got from its Puppet implementation. That’s well and good, but the bit that stuck with me was the casual way a cross-platform management tool brought together previously siloed entities within his organisation.”

This has affected ISE’s large development staff as well. Not only has Puppet upped software releases from two per year to five, the mechanics of application deployment Puppet enables has begun a development/operations integration on a path towards DevOps.

Reading the full article — 2.5 million trades a DAY: How ISE admins became Puppet masters.

The new Puppet Test Pilot program is looking for people like you who can help make our products better (and your life easier). As a Test Pilot, you’ll get to preview new features, vent about current ones, and help the software solve the right problems—yours, of course.

What is the Puppet Test Pilot program?

The Puppet Test Pilot program is our way of getting to know Puppet users better. We’re on a mission to make a ridiculously awesome Puppet experience for you. Isn’t it obvious we need you to make that happen?

What does a Puppet Test Pilot do?

As a Test Pilot, you’ll be invited to a Puppet Test Pilot session every few months, but your participation is not required every time. Puppet Test Pilot sessions are typically one-on-one with you, a Puppet Labs employee, and a prototype of a new product or feature, and take just 20-60 minutes. You’ll be able to try a few tasks with the prototype and we’ll listen closely as you think out loud. Information from the sessions will be used internally to improve our products.

You can participate remotely via web conference or in-person at our office in Portland, Oregon. And for every completed session, you’ll receive an Amazon.com gift card.

How to Join

There are two super easy ways to participate.

1. At Puppetconf, stop by the Puppet Test Pilot booth and spend 20 minutes working with a Puppet Labs employee who’s eager to get your feedback. Find us in the Expo Hall from 10am to 4pm on September 27 & 28.
2. Join the Puppet Test Pilots program to learn about upcoming sessions and participate when it’s convenient for you. Sign up here.

Either method you choose will give you a chance to try early prototypes of our software, and will have a direct impact on our products. We look forward to working with you!

Learn More:

• Sign up for Puppet Test Pilots
• Visit us at PuppetConf

CERN, the European Organization for Nuclear Research, has been in the news lately for their recent observation of the Higgs Boson particle. Like any research facility dealing with big data, they face infrastructure automation challenges in scaling their computing power—and are looking to move beyond homegrown scripts. Enter: Puppet.

A few of our lucky employees got the chance to tour CERN and talk with Gavin McCance of their IT department about their computing needs and plans to build out their infrastructure. Hear what he has to say in this short video (<2 minutes) below:

Video Transcript:

I’m Gavin McCance, I work in the CERN IT department, I look after the grid compute services and the batch compute services that we use to analyze the data from the Large Hadron Collider experiment. We’re here at CERN with the Puppet Labs guys today. So what does CERN do? It’s involved in fundamental research, so we have a large underground collider looking for new fundamental particles. In fact, last week we discovered the Higgs Boson, which has been searched for for the last fifty years.

Six months ago we started looking outside for open source tools to help manage our infrastructure, and we settled on Puppet. We’ve been having really great experiences with Puppet, so we’ve been discussing with the Puppet Labs guys here today, and we’re very very happy with Puppet. What we’re doing now is in 2013, we’re getting a new computing center, we’re expanding our computing resources, and that center will be entirely Puppet-managed, and over the next two years we’ll be migrating our production infrastructure, the computers here, to Puppet as well. So we’re really looking forward to working with Puppet. Thank you.

Learn More:

• VIDEO: Onwards to a Puppet Infrastructure at CERN from Puppet Camp Geneva
• CERN Infrastructure Evolution
• CERN
• CERN Puppet modules on GitHub
• More on Higgs Boson from the BBC: Higgs boson-like particle discovery claimed at LHC

Just a few years ago in 2009, Puppet Labs hosted their first Camp around Puppet. That camp had about 60 people in San Francisco, and I was lucky enough to be one of them. At the time, 60 people felt like nearly the entire community using Puppet. We learned a couple things at that conference.

1. The Puppet Community was really smart and amazing.
2. Puppet Camp was just as much about operations as Puppet.

In 2010, we expanded to Europe and had 80 people in attendance, then 100 in 2010 for Puppet Camp North America. In 2011, we ramped up with a European camp with 200 people, plus the first PuppetConf with 300+ people in Portland, OR.

PuppetConf was a huge success, and we are doing it again this year in San Francisco. Outside of PuppetConf, camps have gone viral on the ground. When a community comes together, we’ve been trying to respond by creating regional camps. We’ve had camps thus far in Atlanta, Edinburgh, Stockholm, Amsterdam, New York, Los Angeles. We’ve got upcoming camps in Dublin, Geneva, Chicago, Oslo, Nuremberg, Sydney and Kuala Lumpur open for registration. There are even more camps we are considering doing later in the year. Each of our camps this year have had at least 100 people, with Stockholm topping out at 180.

We love these camps, and they are largely community-driven. When a community rallies around a location, Puppet Labs tries to respond with getting people on the ground and sharing stories.

By the end of the year, we anticipate more than 3,000 system administrators will have been to Puppet event. This doesn’t count the growing numbers of Puppet User Groups, Puppet Hack events, Triage-a-thon participants, and community contributors.

We are still looking for speakers for the several of the upcoming camps, as well as PuppetConf. Speaking at PuppetConf is up, and you can submit a talk on the website. For camps you can email stahnma@puppetlabs.com or jose@puppetlabs.com and we’ll try to get things set up.

Thanks for an awesome experience thus far with our community events, and we look forward to seeing you at one soon.

Learn More

• Videos from PuppetConf 2011
• Call for Speakers PuppetConf 2012
• Puppet Camp Registration

We’re happy to announce three European Puppet Camps:

Edinburgh, Scotland March 23 (only 20 tickets left!)

Register

Stockholm, Sweden March 28 (20 tickets left!)

Register

Amsterdam, Netherlands April 2

Register

Puppet Camps are 1-day community events for local audiences. Typically we’ll feature 3-5 local speakers along with a Puppet Labs Engineer. Schedules for all three Puppet Camps are available, but may change as more talks are submitted.

Teyo Tyree, the VP of Business Development and co-founder of Puppet Labs, will be at all three events. RI Pienaar, the creator of MCollective (the backbone of Puppet Enterprises Live Management feature), will also be at Edinburgh. Core contributors to the Puppet project and interesting users are participating in all of the camps.

Puppet Camp Edinburgh is hosted in conjunction with FLOSS UK’s spring conference. Puppet Camp Amsterdam is being co-hosted by Cloudera and (Puppet Labs’ local partner) AmazicSource. We’re in the process of expanding Puppet Camps from a bi-annual format to a roadshow appearing frequently throughout the year.

This year we are planning to hit New York, DC, Chicago, and either Melbourne or Sydney, but we’re also having conversations with organizers in Berlin and Geneva. If you think your city has enough interest in Puppet to support a 100+ person event, shoot us an email.

Our end user conference PuppetConf will be held at the Mission Bay Conference Center in San Francisco, CA on September 27th and 28th. Look for more details on PuppetConf in the next few weeks, along with a call for participation.

Hello, I’m Michael Stahnke and I’m the new community manager at Puppet Labs. I’ll provide a little bit of background about myself, but then I want to jump into the important stuff around the Puppet community.

I joined Puppet Labs in April of 2011 as the first Release Manager. I was a member of the community and using Puppet since late 2006. I learned about Puppet from being a member of the Fedora Project’s Infrastructure group. I also was one of the people helping get EPEL launched (Extra Packages for Enterprise Linux) very early on. I still contribute regularly to Fedora/EPEL, and of course to Puppet, Facter, Dashboard, Hiera and Mcollective. I also love Infrastructure Operations.

There’s obviously a ton I could write about in regards to community. The community around Puppet is awesome. It’s certainly a key reason I wanted to use Puppet, learn about it, learn Ruby, and join Puppet Labs. Today I’d like to focus on what my goals for the community are, and address some areas where we’ve fallen short in the past.

My main goal for the Puppet Community shouldn’t be any different than the goals of the Puppet project:

I want infrastructure problems to go away.

I want quality system administrators to have more time to explore their domain, and make their infrastructure services an investment rather than a cost center. I want infrastructure engineers to spend time on differentiating activities rather than having every shop reinvent time synchronization, DNS management, and authentication setups.

One of the real reasons I liked Puppet when I got started with it was the community. There were smart people here. I don’t just mean people good at Puppet, but people who solved difficult systems management problems. The people in the community discussed solutions for provisioning, patching, packaging, deployment, compliance, auditing, disaster recovery and everything else that was consuming my day as an infrastructure admin. So the Puppet community centered (and centers) around people who were (and are) awesome at infrastructure. I’m very interested in continuing to foster those types of discussions.

Beyond that, I have some more concrete goals around community and Puppet.

I’d like to enable the community to host Puppet User Groups or meet-ups. This means developing a formula for what works, a budget process, and hopefully the output is something like a “user-group-in-a-box” kit.

I want to define and recognize contributors. We spend a lot of time focused on contributors providing us with code. We love you, please keep doing it. We also want contributors to be recognized for things like documentation, filing excellent bug reports, leading/attending user groups, uploading modules to the forge, integrating Puppet with other tools, etc.

In the current event bucket, we have the process around Google Summer of Code 2012. We participated in GSOC in 2010, and liked it a lot. This year we’d like to participate again. This means we need awesome ideas for projects. We’ve started an idea page at http://projects.puppetlabs.com/projects/puppet/wiki/GSOC12, please contribute if you have any ideas for GSOC 2012.

In sitting down to identify gaps in the community, or friction points, a few items bubbled up quickly. So, we’re going to address them as soon as we can.

1. It is difficult to find material about the Open Source projects on our main website.
2. We don’t do a super job recognizing members of the community.
3. We don’t capture a lot of information about what you, the community, are doing. This type of input can make our product and documentation much better.

In the near future, look for some new content on our website, around community and the open source ecosystem.

I have several ideas on what we’ll do to fix these gaps. Some of this will require some patience and experimentation to get right as well. If you have comments and suggestions around the Puppet community, I’m available via Twitter (@stahnma), Freenode (stahnma), and email (stahnma@puppetlabs.com).

Look for a lot more to come in the future around community goals and involvement.

Additional Resources

• Contribute a Google Summer of Code project idea
• Join a user list: Puppet users and Puppet Enterprise users
• The Puppet Labs projects page
• The Puppet Module Forge
• The Puppet Labs GitHub

Puppet Camp Atlanta was a fantastic community event and is be the template for our continuing Puppet Camp series. In many ways Atlanta was an experiment to see if our community could support a 1-day event structure. It can, and the meeting was productive and filled with rich content. A loose speaking schedule allowed for a lot of great conversations over coffee and open Q&A sessions with Puppet Engineers. More than ever before, the Puppet team felt as though we were able to connect with participants to help tackle the tough issues that our users face in real world situations. I strongly encourage you to participate in an upcoming Puppet Camp in your city.

We have 7 Puppet Camps in the works, so look for your city on our complete list. If you don’t see your greater area represented and think you can help us find 100 puppeteers eager to converse, reach out and we’ll see what we can do to bring an event to your city.

And don’t forget PuppetConf is September 27th and 28th at the Mission Bay Conference Center in San Francisco, California. A call for participation, registration details, and sponsorship prospectus will be available by March. PuppetConf has an estimated 60 speaking opportunities and will span all topics operations, DevOps, Puppet, and the Puppet Ecosystem.