Advisory Third Party CI
Spencer Krum
Testing - Monday, 1/2/2016 14:00 - B.CON
Advisory Third Party CI Third party CI is a relatively new concept (to me at least) that will be introduced in this talk, and expanded on. I'll show the ways we do this already in the OpenStack and Puppet communities, and lay out my vision for how we can do this at at much larger scale. Third party advisory CI is the process of a third party providing CI information to the development team of a project. These individuals or projects are not core developers, and the CI system stands next to the main CI for the project. The CI vote is advisory, and doesn't block merge. Imagine Project A is a library. Project B is a web application that consumes that library. Whenever a patch is proposed to project A, Project B's CI system runs a test of Project B's software using Project A's master + proposed changes. Then the result of that test is reported back to the developers of Project A. In this way, Project B can inform Project A that the change would break Project B's use of Project A. There are a number of different ways this can be configured, and a couple cool emergent behaviours with this. With the projects I am currently involved in, we are using some form of it with both gerrit and github. This presentation will present the idea, some configuration examples, and my vision for the future. I don't think this is 100% figured out, so I'll leave some time in the session for audience feedback and discussion. There are place where the tools we have need to be improved to support this, I'll call those out as well.
Slides: Advisory Third Party CI Github: Source Code
Better Together! Puppet and Ansible
Spencer Krum
On the OpenStack Infrastructure team, we fire our Puppet runs from Ansible. We split the responsibilities of these tools: Puppet performs configuration management, Ansible performs orchestration. In this talk, we'll talk about what prompted us to create this system, what we've been able to do with it, and where we are going next. We'll describe the setup of our systems and network. We'll also show you some things that we tried that didn't work, so that you don't have to make the same mistake. Everything you see in this talk is 100% Open Source and running live on the OpenStack Infrastructure servers. We've developed some high level patterns that you can take back to your sites to start using immediately. What you will learn: What (in our opinion) Puppet and Ansible each do best. How to compose configuration management tools. How to develop, store, and run your config mgmt code in the open. How to consume other Open Source Ansible playbooks and Puppet modules. What it looks like to layer them more than once.
Slides: Better Together Github: Source Code
Orchestration - Tuesday, 2/2/2016 12:20 - B1.017
About Spencer Krum
Spencer (nibalizer) Krum has been sysoping Linux since 2010. He works for IBM contributing upstream to OpenStack and Puppet. Spencer is a core contributor to the OpenStack Infrastructure Project. Spencer coordinates the local DevOps user group in Portland and volunteers for an ops-training program at Portland State University called the Braindump. Spencer is a published author and frequent speaker at technical conferences. Spencer helped found the puppet-community effort, which attempts to bring together a network of developers, modules, and infrastructure. Spencer lives and works in Portland, Oregon where he enjoys cheeseburgers and StarCraft II.