Open Stack

Hi everyone,

At the TC meeting yesterday we discussed Rally program request and
incubation request. We quickly dismissed the incubation request, as
Rally appears to be able to live happily on top of OpenStack and would
benefit from having a release cycle decoupled from the OpenStack
"integrated release".

That leaves the question of the program. OpenStack programs are created
by the Technical Committee, to bless existing efforts and teams that are
considered *essential* to the production of the "OpenStack" integrated
release and the completion of the OpenStack project mission. There are 3
ways to look at Rally and official programs at this point:

1. Rally as an essential QA tool
Performance testing (and especially performance regression testing) is
an essential QA function, and a feature that Rally provides. If the QA
team is happy to use Rally to fill that function, then Rally can
obviously be adopted by the (already-existing) QA program. That said,
that would put Rally under the authority of the QA PTL, and that raises
a few questions due to the current architecture of Rally, which is more
product-oriented. There needs to be further discussion between the QA
core team and the Rally team to see how that could work and if that
option would be acceptable for both sides.

2. Rally as an essential operator tool
Regular benchmarking of OpenStack deployments is a best practice for
cloud operators, and a feature that Rally provides. With a bit of a
stretch, we could consider that benchmarking is essential to the
completion of the OpenStack project mission. That program could one day
evolve to include more such "operations best practices" tools. In
addition to the slight stretch already mentioned, one concern here is
that we still want to have performance testing in QA (which is clearly
essential to the production of "OpenStack"). Letting Rally primarily be
an operational tool might make that outcome more difficult.

3. Let Rally be a product on top of OpenStack
The last option is to not have Rally in any program, and not consider it
*essential* to the production of the "OpenStack" integrated release or
the completion of the OpenStack project mission. Rally can happily exist
as an operator tool on top of OpenStack. It is built as a monolithic
product: that approach works very well for external complementary
solutions... Also be more integrated in OpenStack or part of the
OpenStack programs might come at a cost (slicing some functionality out
of rally to make it more a framework and less a product) that might not
be what its authors want.

Let's explore each option to see which ones are viable, and the pros and
cons of each.

-- 
Thierry Carrez (ttx)