Thursday, Kirkland, 11:30

Being on the bleeding edge of master is bumpy From 3 to 4 was DSL changes Big thing for Omnibus 3 was Git caching, which had issue

Overview of things that have changed in the last major version

Bloomberg, trying to build stuff for multiple OSes Questions about best approaches for things like openssl Don't want 5 omnibus installs on the same machine with different dependencies

Yvonne - Releas Engineering Team Seth - Release Engineering Team Tyler - Write Couch Migrations Lance - Open Source, custom build Chef RPCs Scott - Field Solutions, omnibus for Aix (John interested in Aix). Will be doing Rhel, Ubuntu 14, PowerPC and SPARC. A.J. - Pantheon CD pipelines (biggest users of Omnibus 3.x)

All 12 products Chef ships built with Omnibus All updated to Omnibus 4.0, everything but Chef Server 12 (to not impact release) Even build Windows and MSIs, found most bugs there

Changes in Omnibus 4 Common compiler stuff - diverged from 3.x Created branch omnibus-3.2 that slipped under radar that you need to peg to if you are on a omnibus 3 project Most internal engineers understand this, and will be maintaining and backporting to 3.x branch Have issues with UUIDs being set wrong, but can be fixed in postinstall script Omnibus 2.x because of security issues Had issues with fpm 1.0 - fpm has started having dependencies on ffi to build packages, checking for "weird" file types Edge case that caused instability in fpm - rolled back in fpm 0.4, and had a bug Fix was easy - chmod directoy to be secure Want to eliminate dependcy on fpm

Changes in Omnibus 4 Now have a clear public DSL and runs in a cleanroom (also a cleanroom gem). Ran into some weird bugs where people created methods had same names as omnibus, and there were issues Speed improvements - no longer fetch packages as needed, packges are cached in advanced and threaded If you dependend on build order broke things Now building packages for "esoteric platforms" properly, like Aix Before could only build packages from /opt/chef, now changed MSI support, BFF (Aix native packaging) Omnibus is going to work on Aix, now being changed No longer using fpm - it's friends and dependencies caused issues as we extended build matrix Depend on omnibus cookbook to prepare build environment Builders are built with omnibus cookbook

Omnibus cookbook sucks and it's slow Each packager has own way to generate packages, now you can override the defaults for say a .spec file if you need to edit it Now there are compressors (first compressor, .dmg, for everything elase .tar.gz) Now explicit support in the DSL for file operations (copy, sync, mkdir, etc. Now set ldflags properly to something not stupid (cleaned up a lot of "copy pasta" that was copied between projects incorrectly, engineers don't understand nuance of all the flags). Now creates a hash with all flags that you can override. (Definitions file for openssl is now teeny). Have default make

Hash crazy-useful for Solaris - defaults

DSL option - app_bundle DSL that Dan Wrote - app_bundler - takes Ruby project and if there is a Gemfile.lock it will use it. Will load what is needed in the Gemfile.lock in the environment. ohai and chef are appbundled, puts folder there that is self-contained and isolated. Really only useful for ruby apps. Don't rely on rubygems load order and bundling.

Git caching mechansm, which Adam wrote. Check into local git repo - with checksum - everything after that gets built. Put things that don't change much at the end of the last so it will go faster.

Q: Can you build packages with chroot? Old version needed to build in /var/cache/omnibus, will fix that so you can build in the workspace (say on Jenkins) Very painful to build multiple things on one host otherwise

What do omnibus builds in containers look like? Must faster than omnibus cookbook - takes too long On VM takes too long to build Takes a few minutes

Changes to Docker cookbook revs and image for Chef that shares with the community Idea that you could docker pull/run with 1GB image snapshot that you could just pull would be great Windows in a container - no go

Looking at getting other things running in bsdjails Chef wants big-ass Docker host that devs and CI use for builds Revving of omnibus cookbook will be public on docker Julian & Tom Duffield scoping this out and will spike on this idea Dockfilefile, knife container, push to hub, register in registry

Should have more people working on container stuff in general Don't agree with running Chef in containers Use case is using Chef to build the containers, not run inside the containers Idea of version overrides - export universe of versions that it supports Multiple versions (using for stable channel and testing channel for PHP builds).

Client projects use build version, can yield to one of the dependencies - get build version and software definition from Chef

Move to Omnibus 4 wasn't that painful internally within Chef IF matrix is limited not very painful Version gets computed from lots of things Always rebuilding path matching

At RC1 right now, plan to go to RC2 soon

DSL changes, going from 3 to 4, old definitions may just work and get a shitload of warnings - great that it doesn't break Gave Seth Vargo dedicated time to clean it up and do test coverage Seth gave great talk on cleanroom gem: https://sethvargo.com/the-cleanroom-pattern/

Is omnibus-software repo being officially supported? In 3 could have multiple omnibus software gems. Would like to see omnibus-software is what we ship How to handle people who don't agree but want to build different things Works great for the 12 products Chef ships For now, A.J. and John had forks of omnibus

(Forked for CA certs - MD5 is wrong most of the time) cacert file changes so much What about two or three root CAs, need to run bundles or get in a whole bunch of problems Rewriting selfcert file - devs feel pain because it hits bluecoat RHEL5 is issue, different from RHEL6 & 7 Debian - update ca certs Need to install on system Make it overridable Software definition - where it comes from Make ca server a runtime dependency, put them in ship so they never hit the disk Worries about having multiple omnibus installs on the same machine Would like to "use cacert; use python" OMnibus philosophy is to package everything together Became insanity because people tried install packages in the tree, contain platforms, with .debs can't install one packages into another. Not deleting non-empty directories. Debian/Ubuntu prevent installing same package. Conclusion we came to is disk space is cheap, have multiple packages Need registry of what software is on which machine

openssl would rather have Os handle it Problem becomes consistency against operating systems Cadence for Aix updates is different, for example OMnibus originally designed for building fat packages, could hack around it by overriding health check stuff -wl rpath Could use -ldlibrary path at runtime is good, but avoidable 30 omnibus packages on a box web teams don't use big iron stuff but other teams don't use Would like to use ufs and docker in future Hit Aix and Solaris with bugs Would be great to be able to switch between fat binaries and system libraries

Have omnibus as its own package, then everything else in another - don't care about Ruby Add helper functions to clearroom DSL might be an idea Use kitchen-ci internally and be like travis

Kicking around idea of docker image being the output of a build Each software definition being its own image - every layer can have one and only one parent in docker - like linked clones, for people going down the path with containers Windows builds - compile from source instead of grabbing binaries - bash inside devkit, for example Team would like to be able to compile bash fix Ruby/devkit in Windows is all binary Beholden to upstream release timetable

OpenStack install does complete clearnroom build, big-bang

How is Chef releasing? Using artifactory Stored into current repo in Artifactory, promotion process to stable, talks to packagecloud for automatic promotion https://packagecloud.io/ Now can't rsync Chef buckets because of packagecloud token Be able to choose stability Working with consulting and support so they understand how to use it before announcing publicly Packagecloud is nice Packagecloud you can use their keys to get to packages Consulting is very interested in supporting customers who have no internet access Best thing would be a disk image with all the stuff - .qcow2 or packagecloud Compliance would get burned

In the image, use packer to build distributions ChefDK and other things installed, image to bootstrap OpenStack cluster Mirror whole tree with riprepo Mirror is apache reverse proxy instead of package cloud And SLA like Amazon AMI repos Boxes dual-homed to specific sites as bastion hosts

Documentation is better in OMnibus 4 Fully yard-enabled now Create channel on IRc #chefhacking Keeping open issues triaged and up-to-date Could triage what was there with multiple omnibus packages

Follow up with John from bloomberg

ohai plugin for version management

other pull requests for features and wishlists (hadn't though about using something besides S3 for cache)