Wednesday, Strategy, 11:30

• Convener / Facilitator (???)
• Note-taker @zts

~30

Observation: big difference between writing Chef code and being able to deploy that through the organisation in a safe and hygienic way. A pipeline for cookbook code seems like a way to do this safely.

Promoting cookbooks between dev/test/prod organisations. Alternatively, you could use Chef Environments for this.

Q: What would you use environments for apart from constraining cookbook versions? Adam: manifest of everything - cookbook versions, app versions, container versions, etc.

Observation: Environment cookbook version constraints are challenging to manage when you have a large number of cookbooks in one environment (conflicting transitive dependencies). Solutions: manage the whole set with Berkshelf, reduce scope of environment,

Unconstrained transitive dependencies cause problems - at least, pin to major version. CI pipeline can assert that appropriate constraints are declared, and fail the build otherwise.

Upgrading community cookbooks becomes a challenge when multiple cookbooks depend on the same community cookbook.

Adam: This is a workflow problem, you need to decide (organisationally) when to eat the cost of doing the upgrade.

Q: With jenkins automatically incrementing versions, you must have a lot of cookbooks - what are you doing to clean those up?

A1: #/cb hasn't been a practical issue yet

A2: the Chef server depsolver sometimes picks up a really old version for no obvious reason, prompting a cleanup

Q: Using Berkshelf to pull deps from github, can encounter reproducibility problems if people don't tag correctly, delete tags, etc. How can I do this better?

A: Publish artifacts somewhere and pull from there, instead of depending on mutable sources.

Single-Repo observations:

• several people using single-repo due to github pricing
• one berksfile per cookbook inside the single repo
• perception that tools are predominantly geared towards one-repo-per-cookbook

Q: Doing anything interesting to talk about or look at?

A: Paul(?) talks about his architecture, uses chef-client -z on every node, pushes changes back to an internal service which records node history in git and pushes them onto github.

Q: Scale you're doing this at, #/cb, etc? A: >100 cbs

Q: How can I get a nice view of what changes are made on the node?

A: Check out chef-guard

Q: Why do you use librarian-chef instead of Berkshelf?

A: Were using 2, deprecating that while 3 was still alpha was the last straw prompting a migration. Finds librarian-chef to be more stable.

Cookbook version constraint strategies:

• Environment cookbook constraints
• Separate organisations/chef servers
• Policyfile is relevant here

Automatic Versioning Strategies:

• You own maj/min, Jenkins owns patch
• thor-scmversion to bump the version (but this doesn't work with multiple cb's in one repo)
• single repo needs a lot more custom work, no easy tools for bumping versions
• Q: Any other tools/solutions for bumping versions? A: silence