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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
