OpenStack Mitaka Design Summit

OpenStack is a global community, OpenStack is deployed in many countries. As such, Internationalization (i18n) is essential to the success of OpenStack. The i18n team is a very special team whose contributions, in the form of translations, are of great value to the development and documentation of OpenStack.

In this session we will cover the team structure, how to become part of it, the process to translate OpenStack's different modules and documentation, and the translation tool used to do it (Zanata). The Japanese translation team coordinator will also share his experiences in openstack translation.

Come and join us to learn how to help OpenStack speak your language!

Have you ever had a really interesting idea that you believe could benefit a significant number of OpenStack clouds but you are not a developer so can't contribute code?  Join us in this session to learn about the various ways non-developers can (and need to!) contribute to the OpenStack community. This session not only applies to operators but to any person that has a stake in the future of OpenStack. 

We will cover review and discuss groups that exist inside the OpenStack community that focus on specific market segments and how to get involved with them. We will also introduce the concept of user stories and how to submit them to the newly formed Product Working Group. 

What you will get out of this session:

• An overview of the User Committee and [Working Groups]/teams that exist today


• An understanding of the role that the Product WG plays, how to interact with it, and how its results are used in the community


• Learn how you can submit user stories using the Product WG Repo and Template


• Instructions/demo on how to submit a user story


• Understand the value of work group participation as an OpenStack user

In this talk I will share my experience doing upstream OpenStack development using the OpenStack Ansible Deployment (OSAD) distribution instead of DevStack as my development platform.

OSAD is a production OpenStack distribution for private clouds that deploys upstream OpenStack direct from the official git repositories, without any vendor-specific patches or add-ons. But unlike DevStack, services are isolated from each other in LXC containers, providing more flexibility and less dependency headaches.

In this talk I will give you an introduction to the OSAD project and show you how I use it to contribute code upstream. Topics I will cover during the presentation include: 

• What is OSAD?


• Architecture overview


• How to deploy an OSAD all-in-one for upstream development


• OSAD vs. DevStack: How are they similar, and how are they different?


• Development workflow


• Types of upstream work that work well with OSAD.


• Types of upstream work that do not work well with OSAD.


• Live Demonstration

The “As a…” clause of the classic user story is easily forgotten. To build a feature, we must know what it is and why someone would want it, but as developers we often abstract away the user. Building “the simplest thing that can possibly work” is usually a critical design tool, but without active attention to customer roles and workflows, it can lead to APIs that leak the implementation details of underlying technology or prioritize machine logic over human understanding.

We will use the Unified Job Interface Map feature in the OpenStack Data processing service (sahara)’s Liberty release as a case study in role-aware API design. In addition to demonstrating how this feature can improve communication between data processing developers and cluster operations engineers in your organization, we will examine:

1. Why APIs in the OSS infrastructure and tools space are bound to leak implementation details at some level.


2. Why the ideal of an API flow that is intuitive to any user from any entry point is likely a fool’s errand.


3. Why multi-role customer flows mean that the “simplest thing that can possibly work” usually doesn't at handoff points between users.


4. How domain-specific awareness of user roles allows smart choices about where to go ahead and leak implementation details and where to build a dam.


5. How features to facilitate inter-role communication can quite often be built iteratively, on top of existing APIs.

Data processing users will leave this session with details on a powerful model for easing communication between development and operations in Sahara. OpenStack contributors will leave this session with a refreshed perspective on the importance of understanding not only the use case, or even “the user”, but the many roles within an OpenStack customer organization.

Starting in the Kilo cycle OpenStack underwent a change in governance model where the scope of what we call OpenStack has been redefined. The new model is called the "Big Tent", and is much less exclusionary. Prior to this the QA program had a policy of directly supporting any project that was part of OpenStack, meaning tests in tempest, support in devstack for running them, etc. However in a model where there are far more projects considered part of OpenStack it becomes infeasible to directly support all of them. Even before the "Big Tent" was adopted, we realized that this centralized approach did not scale well with the growing number of OpenStack projects. With the "Big Tent" opening up the doors to more projects, the scale issue has become even more compelling. 

As a result of this change in governance model, we have worked on moving QA in OpenStack to a self-service model, where each new project in OpenStack is responsible for writing and maintaining their deployment scripts and tests, as plugins to the tools for deployment and testing frameworks maintained by the QA team.This will allow both the upstream QA efforts to scale organically with the rest of the OpenStack ecosystem but also allow new projects to control their own testing and deployment stories for gating, which can increase development velocity for newer projects.

This talk will cover the work which was done to add external plugin interfaces to Tempest, Devstack, and grenade as well as go into examples on how to use each project's respective interface. It will also show examples where these plugin interfaces are being leveraged today.

You are developer, and you have just been told to work with OpenStack. Welcome to the OpenStack community! You have also just been told you need to release your product next month, you have your all the codeyou’re your new feature complete, and a few bug fixes done. Now you just need to get that pushed upstream. Where do you go next?

You have been working for OpenStack for a while; some internal issues meant you had to stop reading the ML for a month or two. How do you get back in the loop?

You are working hard reviewing specs and code, and the work load is getting crazy, and everyone is saying their use case is the most important thing for OpenStack, and they are all really useful things to consider. What is the right thing to do?

Maybe we can use lessons from Harper Lee's To Kill a Mockingbird improves how new and established OpenStack contributors work together?

John has spent time at Citrix packaing OpenStack for public cloud, then pushing a vendor technology upstream (with an element of coopetition). Since early 2013, he has been working on Rackspace’s public cloud. Mostly recently he served as the Nova PTL for the Liberty release. He is distilling what he has learnt during this journey, and looking to share this experience more widely, and hopes this will help create some great conversations about how we can all work together even more efficiently and effectively.

After figuring out the basics of "How to Contribute to OpenStack" the developer is often faced with a harsh reality. Things can take a long time! Specs and patches can continue for over 50 patch sets, spanning weeks and months. Deadlines due to milestones matter, and getting attention from Core (and non-core) reviewers can be challenging. Scott D'Angelo and Andrea Rosa will provide insight and ideas on 1) what to expect when contributing 2) How the spec process can go 3) Some extreme examples 4) ideas on how to smooth the process In addition, experienced Core/PTL members will give tips and insights into how to contribute and navigate the process.