Icehouse Design Summit

Storyboard is a Django/Bootstrap-based proof-of-concept replacement for task tracking throughout the OpenStack projects. We currently use Launchpad to track those but we are facing a number of limitations, especially in the blueprints side. Writing our own lets us design a system that is closely integrated with other OpenStack infrastructure bits, and precisely matches our development processes and workflow.

The POC currently only contains basic concepts and features and there is a lot of work to do before we can fully replace Launchpad with it. We need a lot more people working on this if we want it to become a reality soon.

This session will introduce the basic concepts behind StoryBoard, map the road ahead and serve to identify interested contributors.

See https://github.com/openstack-infra/storyboard for more.

(Session proposed by Thierry Carrez)

We're pretty self contained and other than bugs on launchpad, don't actually use anything on external sites for real purposes.

However, people find integrations with external sites, such as our replication to github, helpful for their daily lives. On the other hand, having things in multiple locations also has the potential to confuse people (like the angry pull request dude) If we ARE going to do things with an external site, we should probably figure out automation for it, because the tasks of doing it are probably quite lame and boring.

Let's talk about what external things all of our projects should be associated with and managed in automated fashion. Current list of things to think about:

- github
- bitbucket
- rtfd
- ohloh
- launchpad
- freshmeat

(Session proposed by Monty Taylor)

This session will include the following subject(s):

Log management:

We should decide on a plan for how to deal with log storage, processing, serving, etc for all the logs that are produced from our test runs.

See this mailing list thread on the subject:

http://lists.openstack.org/pipermail/openstack-infra/2013-October/000327.html

(Session proposed by James E. Blair)

Job runners for Zuul:

Let's design a non-Jenkins job runner for Zuul. Rough starting requirements:

* Distributed (no centralized 'master' architecture)
* Secure (should be able to run untrusted jobs)
* Should be able to publish artifacts appropriate to a job's security context
* Lightweight (should do one job and simply)


(Session proposed by James E. Blair)

Taking a look at what bits and pieces of Infra could work well with Salt.

(Session proposed by Anita Kuno)

Transifex is used to manage the translations, which now changes to close its source code. This session will re-evalute the available translation tools and have a discussion whether to turn to other open source translation management tools.

This session will also go through the scripts related with translation, the additional requirements, and the improvement plans in Icehouse.

(Session proposed by Ying Chun Guo)

Late in the Havana cycle we introduced elastic-recheck which uses logstash to find known gate bugs when a test run fails. In the short time the bot has been running it has been incredibly useful. Both at identifying known repeating failures and finding new bugs.

Moving forward there are improvements and features we'd like to see added to the bot including but not limited to:
* zeromq triggering from logstash when a test's logs are ready
* a different method of storing/managing queries (lp, in a db, separate git repo, etc.)
* reworking the recheck status page with graphs from logstash and integrating elastic-recheck more closely with the page.

This session will be the place to describe what additional features we should be adding to elastic-recheck and how we can enable the tool to be even more useful and automate more of test failure analysis.

(Session proposed by Matthew Treinish)

Now that we have gotten through a cycle with the requirements project we should discuss what worked, what didnt work, and how things can be improved.

(Session proposed by Chuck Short)

We are currently doing preemptive integration on all the openstack projects needed to run an OpenStack cloud. But we depend on a hundred upstream python packages, which have very mixed track records on their ability to upgrade smoothly. This creates problems all the time during the release, and two weeks of hell right before pycon, as everyone pushes out new major versions.

We can do better.

I'd like to come up for a plan of attack to preemptively integrate the world. Starting with all the python libraries that have moved to stackforge, and expanding to any upstream library that we've had issues with in the past. For non stackforge things this wouldn't be gating, but be informative, and help us understand when problems are coming, and hopefully let us catch bugs in upstream packages before they hit released versions.

(Session proposed by Sean Dague)