1. login
Puppetmanaged.org
How to use it in
your
environment
2. id
uid=500(Yaakov M. Nemoy) gid=500(Human)
groups=10(wheel),501(Fedora Project
Ambassador),502(Puppetmanaged.org
Developer),503(RHCE),666(UMC Utrecht BOFH)
3. elinks
● Puppetmanaged.org is a collection of (mostly)
standalone common puppet modules for per
service deployment of your infrastructure
● It's designed around principles of good
configuration management
6. elinks
● Each module contains
● A bunch of file declarations
● Gets your service up and running
● RHEL default configurations
● Well defined classes with logical meaning
● Every class has a disabled subclass for cleanup
● A pony – development, testing, and production
branches
7. elinks
● pm.org is file based – just deliver the files and
get out of the way
● There are five options for file locations
● Environment + Host
● Environment
● System Wide + Host
● System Wide
● PM.org default
10. elinks
● Uses definitions to create pseudo resources
● Makes these modules very easy to adopt
● Easy to deploy in your current infrastructure,
one module at a time
● Easy to collaborate with upstream on
12. make
● All you need is a git repo with a directory per
module
● Each branch is a seperate environment
● The master branch is the site-wide
configuration
● The pm.org puppet module handles the rest
13. make
● Some services require OS version specific files,
then you get twenty options
● OS + minor version
● OS + major version
● OS
● Default
● For example:
● pam
15. make install
● Actually this slide should be
febootstrap/debootstrap
16. git svn
I can't talk about how to fix this in your
environment...
17. git svn
Or can i?
[Insert Shamless Hire Me Plug]
18. git svn
The UMC Utrecht DBG née Genomics Center is
a public institution, so we can talk about how we
solved the problem there
19. git foo
● There are good gateways for git and other
source control
20. git svn
● We started with an old experimental version of
pm.org
● conf/manifests – this is our site manifest
● distr/modules – one git repo per module
● distr/files – legacy files
● distr/files/private – file domain structure
● We only have one environment currently
21. git branch
● Each repo is cloned into the svn, then branched
to a umc specific branch
● Since we're using svn, i freely use git rebase,
so it's obvious which patches are not yet
upstream
● The diff between development and umc is
meant to be as short as possible
22. emacs
● Our umc branches normally just edit file
locations and comment out code defined in
legacy
● UMC specific classes are in
conf/manifests/classes/*pp
23. git rebase
● Every time i commit to git, i can also commit it
to our SVN
● Everytime someone else commits to svn, i can
rebase the git on top
24. git push
● Commiting is then very easy, just switch to the
right branch and push
● git format patch is great
● There is a devel mailing list open for patches
● Frequent patchers can probably get commit
access
25. publican
● Documentation is yet another git repo
● We store it at documentation/
● We branch and merge like usual
26. make install
● Move all code into modules or classes
● Migrate to pm.org's puppet module managing
site.pp
● Sort all files into distr/files/private
● Ensure every module we have is pm.org quality
27. make install
● Move each git repo to its own toplevel in svn
(except maybe distr/modules)
● git-svn handles mapping svn branches
● Fix the puppet module to do svn too
28. cat /dev/future
● Environments per working group
● Each group has write access to their own branch
● Porcelain – extensions on top of pm.org
standard
● More modules
● Better integration with external nodes
31. questions?
● loupgaroublond@gmail.com
● loupgaroublond on practically every social
network, especially freenode
● #ergo@freenode.net
● Or just annoy kanarip
● the one with the ugly haircut
