|09:00 – 09:15||#Welcome
(Robert Collins, HP & Joshua Hesketh, Rackspace Australia)
|09:15 – 09:45||
#OpenStack Identity and Federation
(Jamie Lennox, Red Hat)
Keystone is the central authentication and authorization point for OpenStack.
For the unfamiliar, we’ll start with a quick recap of the role of Keystone and
|09:55 – 10:25||
#Python Build Reasonableness and Semantic Versioning
(Robert Collins, HP)
Semver and Python with PBR
The most interesting part is the version number creation, since coming up with the right version number can be a contentious discussion in some projects. Semver provides simple and robust rules for deciding on version numbers, and I’m in the middle of implementing automation for these in PBR itself, with integration glue to export them in PEP-440, dpkg and rpm format. The only dependencies PBR has are git + a recent pip, so this should be useful for many attendees – and while PBR is an OpenStack invention we’re very interested in making sure its useful and reliable for anyone that wants to use it.
|10:25 – 10:45||Morning Tea|
|10:50 – 11:20||
#Tempest: OpenStack Integrated Testing
(Matthew Treinish, HP)
Tempest is OpenStack’s integrated test suite which aims to provide validation that OpenStack is working. As such it is run as a gating on job on all proposed commits to OpenStack. It is designed to run against an operational OpenStack cloud, which includes everything from a devstack deployment to a public cloud. Tempest originally started as just a small number of integration tests to verify that the various OpenStack projects worked together. It has since grown into one of the top 5 most active OpenStack projects with several different classes of testing and validation.
This talk will provide an overview of what Tempest is and how it works. Providing an explanation of the philosophy behind the project, and insight into why things are setup a certain way. Additionally, it will cover some of the features in tempest and how to configure and run it locally with or without devstack.
|11:30 – 12:00||
#Changing the world with ZeroVM and Swift
(Jakub Krajcovic, Rackspace Australia)
ZeroVM is a new generation of virtualization. It provides a secure sandbox for executing code and is able to spawn in under 5ms. It natively supports python execution out of the box.
This talk aims to outline how ZeroVM and Swift can start changing how we fundamentally think about computing and the consumption of IT resources. ZeroVM could be thought of as a “”micro-hypervisor”” that creates a sandboxed environment for code execution and through python middleware can run natively on top of a Swift storage cluster. This talk will present ZeroVM, describe about how it plugs into Swift and what capabilities the combination of these technologies opens.
The most immediate “”killer apps”” that the Swift+ZeroVM combination offers are in data processing:
Some less obvious but even more interesting are things like the possibility to completely redesign an SQL DB and create a structured query language that processes binary unstructured data instead of rows and columns.
|12:00 – 13:30||Lunch|
|13:30 – 14:00||
#Deploy your python app into an OpenStack cloud using Solum
(Angus Salkeld, Rackspace Australia)
This talk will give an introduction to Solum and show how you can use Solum to Deploy an application into an OpenStack cloud.
A short video of Solum in action will be shown to give the audience an idea of the problem that Solum is trying to solve.
The presenter will then go through some of the capablities of Solum and some future features that are been worked on.
|14:10 – 14:40||
(Grant Murphy, Red Hat)
This session will look at the historical trend of vulnerabilities that have been found in OpenStack, how they are managed and the initiatives that the OpenStack security group currently is undertaking to help reduce future occurrences.
|14:50 – 15:20||
#TripleO – What, Why, How
(James Polley, HP)
What is(n’t) TripleO?
|15:20 – 15:40||Afternoon Tea|
|15:45 – 16:15||
#How to Read the Logs
(Anita Kuno, HP)
OpenStack generates a lot of log files in its testing process. Learn how to find and identify common patterns in log files from a member of the OpenStack Infrastructure team. Understand the different kinds of log files to expect, how to evaluate them to find why your patch is failing and what steps to take when you identify the failure. Learn how to search for bugs and how to file a bug report. Understanding the value that elastic-recheck provides will also be covered.
|16:25 – 16:55||
#Large Scale Identification of Race Conditions (In OpenStack CI)
(Joseph Gordon, HP)
“Does your project have a CI system that suffers from an ever-growing set of race conditions? We have the tool for you: it has enabled increased velocity despite project growth.
When talking about the GNU HURD kernel, Richard Stallman once said, “it turned out that debugging these asynchronous multithreaded programs was really hard.” With 30+ asynchronous services developed by over 1000 people the OpenStack project is an object lesson of this problem. One of the consequences is race conditions often leak into code with no obvious defect. Just before OpenStack’s most recent stable release we were pushing the boundaries of what was possible with manual tracking of race conditions. To address this problem we have developed an ElasticSearch based toolchain called “elastic-recheck.” This helps us track race conditions so developers can fix them and identify when CI failures are related to the failed patch or are due to a known pre-existing race condition. Automated tracking of over 70 specific race conditions has allowed us to quickly determine which bugs are hurting us the most, allowing us to prioritize debugging efforts. Immediate and automated classification of test failures into genuine and false failures has saved countless hours that would have been wasted digging through the over 350MBs of logs produced by a single test run.”
|16:55 – 17:10||#Close
(Robert Collins, HP & Joshua Hesketh, Rackspace Australia)