Open Stack

On 05/23/2017 05:47 AM, Sagi Shnaidman wrote:
> Hi, all
>
> I'd like to propose an idea to make one or two days hackathon in TripleO
> project with main goal - to reduce deployment time of TripleO.
>
> - How could it be arranged?
>
> We can arrange a separate IRC channel and Bluejeans video conference
> session for hackathon in these days to create a "presence" feeling.
>
> - How to participate and contribute?
>
> We'll have a few responsibility fields like tripleo-quickstart,
> containers, storage, HA, baremetal, etc - the exact list should be ready
> before the hackathon so that everybody could assign to one of these
> "teams". It's good to have somebody in team to be stakeholder and
> responsible for organization and tasks.
>
> - What is the goal?
>
> The goal of this hackathon to reduce deployment time of TripleO as much
> as possible.
>
> For example part of CI team takes a task to reduce quickstart tasks
> time. It includes statistics collection, profiling and detection of
> places to optimize. After this tasks are created, patches are tested and
> submitted.
>
> The prizes will be presented to teams which saved most of time :)
>
> What do you think?

I'm happy to see this get more attention, and I will take this 
opportunity to point out 
http://blog.nemebean.com/content/improving-tripleo-ci-throughput which 
discusses the work I did a few months ago to decrease the ci wall time. 
Some of that was ci-specific, some of it was general bugs in TripleO 
performance.

However, the important thing to note is the last couple of paragraphs. 
I spent a _lot_ of time tracking down performance issues and optimizing 
things where I could, and in the end pretty much every gain I made was 
regressed somewhere else within a few weeks, leaving us where we are now 
with jobs timing out all over the place.

I guess my point is two-fold: 1) I'm not sure a day or two sprint is 
going to be sufficient to dig into and fix the performance of TripleO. 
Maybe if there's some low-hanging fruit.  2) It's certainly not going to 
be sufficient to keep TripleO performance at an acceptable level 
long-term.  This will have to be an ongoing effort, and we badly need 
the tracking previously provided by our graphite metrics.  Without hard 
numbers on what is regressing we don't know what to look at.  Related: 
https://review.openstack.org/#/c/462980

-Ben