<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 6, 2014 at 5:30 AM, Thierry Carrez <span dir="ltr"><<a href="mailto:thierry@openstack.org" target="_blank">thierry@openstack.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi everyone,<br>
<br>
At the TC meeting yesterday we discussed Rally program request and<br>
incubation request. We quickly dismissed the incubation request, as<br>
Rally appears to be able to live happily on top of OpenStack and would<br>
benefit from having a release cycle decoupled from the OpenStack<br>
"integrated release".<br>
<br>
That leaves the question of the program. OpenStack programs are created<br>
by the Technical Committee, to bless existing efforts and teams that are<br>
considered *essential* to the production of the "OpenStack" integrated<br>
release and the completion of the OpenStack project mission. There are 3<br>
ways to look at Rally and official programs at this point:<br>
<br>
1. Rally as an essential QA tool<br>
Performance testing (and especially performance regression testing) is<br>
an essential QA function, and a feature that Rally provides. If the QA<br>
team is happy to use Rally to fill that function, then Rally can<br>
obviously be adopted by the (already-existing) QA program. That said,<br>
that would put Rally under the authority of the QA PTL, and that raises<br>
a few questions due to the current architecture of Rally, which is more<br>
product-oriented. There needs to be further discussion between the QA<br>
core team and the Rally team to see how that could work and if that<br>
option would be acceptable for both sides.<br></blockquote><div><br></div><div>Pros: Performance testing is great and we don't have it now that I know of.</div><div>Considerations: </div><div>- QA then takes on more scope in their mission. Do they want it? </div>
<div>- Is Rally actually splittable this way?</div><div>- How important is the PTL role - PTL cage match may ensue next election?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2. Rally as an essential operator tool<br>
Regular benchmarking of OpenStack deployments is a best practice for<br>
cloud operators, and a feature that Rally provides. With a bit of a<br>
stretch, we could consider that benchmarking is essential to the<br>
completion of the OpenStack project mission. That program could one day<br>
evolve to include more such "operations best practices" tools. In<br>
addition to the slight stretch already mentioned, one concern here is<br>
that we still want to have performance testing in QA (which is clearly<br>
essential to the production of "OpenStack"). Letting Rally primarily be<br>
an operational tool might make that outcome more difficult.<br></blockquote><div><br></div><div>Pros: Great start to an operator program for tooling. </div><div><br></div><div>Considerations: </div><div>- Would have to ensure Rally is what we want "first" as getting to be PTL since you are first to propose seems to be the model. </div>
<div>- Is benchmark testing and SLA-meeting a best first tool? Or monitoring? Or deployment? Or some other tools?</div><div>- Is this program what operators want? </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
3. Let Rally be a product on top of OpenStack<br>
The last option is to not have Rally in any program, and not consider it<br>
*essential* to the production of the "OpenStack" integrated release or<br>
the completion of the OpenStack project mission. Rally can happily exist<br>
as an operator tool on top of OpenStack. It is built as a monolithic<br>
product: that approach works very well for external complementary<br>
solutions... Also be more integrated in OpenStack or part of the<br>
OpenStack programs might come at a cost (slicing some functionality out<br>
of rally to make it more a framework and less a product) that might not<br>
be what its authors want.<br>
<br></blockquote><div><br></div><div>Pros: Rally can set the standards for this path and lead on this pioneer trail.</div><div><br></div><div>Considerations: </div><div>- Would this tool be applied against continuously-deployed clouds?</div>
<div>- Is there any preference or advantage to be outside of integrated releases?</div><div>- Will people believe it's official?</div><div><br></div><div>Hopefully that summarizes how I'm looking at this application -- </div>
<div>Anne</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Let's explore each option to see which ones are viable, and the pros and<br>
cons of each.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Thierry Carrez (ttx)<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font></span></blockquote></div><br></div></div>