Thursday, Strategy, 10:00

• Convener / Facilitator - Stephen Nelson Smith
• Note taker - Jon Cowie

I forgot to note that part down :(

• How do I go from knowing how to use Chef to using it in the real world ** process versus tech problem

• Different patterns for building code and making it work

• Environments is an overloaded term

• Ways to use chef safely ** dev / test / prod environments are fine, but you end up with lots ** semver version constraints ** pin minor versions in test and prod ** new environments for small settings changes ** be carfeul about putting too much logic in the same place, don’t always want to upgrade everything at the same time ** multiple live environments for different settings

• HIstory of chef - before environment, latest is what you get

• envs let you specify what you get

• One environment pattern at Etsy

• Tribal knowledge not documented anywhere

• Problem - what cookbooks do a set of machines get? ** What attributes to different types of machines get? ** What version of features do the machines have? ** Fundamental axes of the problem

• Version constraints ** environment ** runlist cookbook@version ** constraints in metadata ** policyfile

• How do you handle 2 apps on a server requiring different versions of cookbooks ** Hard problem

• Setting attributes ** Where the machine is ** ohai plugins, attributes ** aws - which account the machine is in, look up databag settings

• apps as cookbooks, app components as roles, app instances as environments

• etsy model, environments == constraints, roles == logical grouping of servers, databags==config data

• similar use case, managing customer application doee ** data driven with databag entries, describes app, version to deploy, map customer apps to instances

• Environment cookbook pattern seems useful to build artifacts of apps to be deployed to customers ** similar model without berkshelf used by some people

• Additional problem is writing cookbooks for customer apps ** A lot of cookbooks to maintain ** How to you reuse? ** Fork community cookbooks, but then they drift ** Enabling and disabling different components ** Scott R used to only change default settings if you have a compelling reason ** Default might not always make sense everywhere though ** Fine tuning things for different devices, ie cloud or physical devices ** Entirely bespoke settings for each customer etc makes it harder to reuse etc

• Reusable cookbooks and generic cookbooks are different problems ** Consistent interface, different implementation helps a lot ** Updating community cookbooks and bring in changes when you’ve changed stuff is hard. ** Treat cookbooks as API versions

• Guidance needed on good workflows to solve different types of problems
• Body of case studies of real world approaches needed