<div dir="ltr">Matt, <div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-family:arial,sans-serif;font-size:13px">One thing did just occur to me while writing this though it's probably worth<br>
</span><span style="font-family:arial,sans-serif;font-size:13px">investigating splitting out the stress test framework as an external<br></span><span style="font-family:arial,sans-serif;font-size:13px">tool/project after we start work on the tempest library. [3]</span></blockquote>
<div><br></div><div><br></div><div>I fully agree with the fact that stress testing doesn't belong to Tempest. </div><div><br></div><div>This current thread is all about this aspect and all my arguments, related to splitting Rally and merging it to tempest are related to this. </div>
<div><br></div><div><br></div><div>Could you please elaborate, why instead of ready solution "Rally"  that has community and is aligned with OpenStack and OpenStack processes you are going to create from scratch similar solution?  </div>
<div><br></div><div>I really don't see any reasons why we need to duplicate existing and working solution and can't just work together on Rally?</div><div><br></div><div><br></div><div>Best regards,</div><div>Boris Pavlovic</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 15, 2014 at 1:15 AM, Matthew Treinish <span dir="ltr"><<a href="mailto:mtreinish@kortar.org" target="_blank">mtreinish@kortar.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Wed, Aug 13, 2014 at 03:48:59PM -0600, Duncan Thomas wrote:<br>
> On 13 August 2014 13:57, Matthew Treinish <<a href="mailto:mtreinish@kortar.org">mtreinish@kortar.org</a>> wrote:<br>
> > On Tue, Aug 12, 2014 at 01:45:17AM +0400, Boris Pavlovic wrote:<br>
> >> Keystone, Glance, Cinder, Neutron and Heat are running rally performance<br>
> >> jobs, that can be used for performance testing, benchmarking, regression<br>
> >> testing (already now). These jobs supports in-tree plugins for all<br>
> >> components (scenarios, load generators, benchmark context) and they can use<br>
> >> Rally fully without interaction with Rally team at all. More about these<br>
> >> jobs:<br>
> >> <a href="https://docs.google.com/a/mirantis.com/document/d/1s93IBuyx24dM3SmPcboBp7N47RQedT8u4AJPgOHp9-A/" target="_blank">https://docs.google.com/a/mirantis.com/document/d/1s93IBuyx24dM3SmPcboBp7N47RQedT8u4AJPgOHp9-A/</a><br>

> >> So I really don't see anything like this in tempest (even in observed<br>
> >> future)<br>
><br>
> > So this is actually the communication problem I mentioned before. Singling out<br>
> > individual projects and getting them to add a rally job is not "cross project"<br>
> > communication. (this is part of what I meant by "push using Rally") There was no<br>
> > larger discussion on the ML or a topic in the project meeting about adding these<br>
> > jobs. There was no discussion about the value vs risk of adding new jobs to the<br>
> > gate. Also, this is why less than half of the integrated projects have these<br>
> > jobs. Having asymmetry like this between gating workloads on projects helps no<br>
> > one.<br>
><br>
> So the advantage of the approach, rather than having a massive<br>
> cross-product discussion, is that interested projects (I've been very<br>
> interested for a cinder core PoV) act as a test bed for other<br>
> projects. 'Cross project' discussions rather come to other teams, they<br>
> rely on people to find them, where as Boris came to us, said I've got<br>
> this thing you might like, try it out, tell me what you want. He took<br>
> feedback, iterated fast and investigated bugs. It has been a genuine<br>
> pleasure to work with him, and I feel we made progress faster than we<br>
> would have done if it was trying to please everybody.<br>
<br>
</div></div>I'm not arguing whether Boris was great to work with or not. Or whether there<br>
isn't value in talking directly to the dev team when setting up a new job. That<br>
is definitely the fastest path to getting a new job up and running. But, for<br>
something like adding a new class of dsvm job which runs on every patch, that<br>
affects everyone, not just the project where the jobs are being added. A larger<br>
discussion is really necessary to weigh whether such a job should be added. It<br>
really only needs to happen once, just before the first one is added on an<br>
integrated project.<br>
<div class=""><br>
><br>
> > That being said the reason I think osprofiler has been more accepted and it's<br>
> > adoption into oslo is not nearly as contentious is because it's an independent<br>
> > library that has value outside of itself. You don't need to pull in a monolithic<br>
> > stack to use it. Which is a design point more conducive with the rest of<br>
> > OpenStack.<br>
><br>
> Sorry, are you suggesting tempest isn't a giant monolithic thing?<br>
> Because I was able to comprehend the rally code very quickly, that<br>
> isn't even slightly true of tempest. Having one simple tool that does<br>
> one thing well is exactly what rally has tried to do - tempest seems<br>
> to want to be five different things at once (CI, instalation tests,<br>
> trademark, preformance, stress testing, ...)<br>
<br>
</div>This is actually a common misconception about the purpose and role of Tempest.<br>
Tempest is strictly concerned with being the integration test suite for<br>
OpenStack, which just includes the actual tests and some methods of running the<br>
tests. This is attempted to be done in a manner which is independent of the<br>
environment in which tempest is run or run against. (for example, devstack vs a<br>
public cloud) Yes tempest is a large project and has a lot of tests which just<br>
adds to it's complexity, but it's scope is quite targeted. It's just that it<br>
grows at the same rate OpenStack scope grows because tempest has coverage for<br>
all the projects.<br>
<br>
Methods of running the tests does include the stress tests framework, but that<br>
is mostly just a method of leveraging the large quantity of tests we currently<br>
have in-tree to generate load. [1] (Yeah, we need to write better user docs<br>
around this and a lot of other things) It just lets you define which tests to<br>
use and how to loop and distribute them over workers. [2]<br>
<br>
The trademark, CI, upgrade testing, and installation testing are just examples<br>
of applications where tempest is being used. (some of which are the domain of<br>
other QA or Infra program projects, some are not) If you look in the tempest<br>
tree you'll see very little specifically about any of those applications.<br>
They're all mostly accomplished by building tooling around tempest. For example:<br>
refstack->trademark, devstack-gate->ci, grenade->upgrade, etc. Tempest is just a<br>
building block that can be used to make all of those things. As all of these<br>
different use cases are basically tempest's primary consumer we do have to<br>
take them into account when working on improving tempest to try and not upset<br>
our "users". But, they are not explicit goals of the tempest project by itself.<br>
<br>
One thing did just occur to me while writing this though it's probably worth<br>
investigating splitting out the stress test framework as an external<br>
tool/project after we start work on the tempest library. [3]<br>
<br>
<br>
<snip><br>
<div class="">>><br>
>> So firstly, I want to say I find these jobs troubling. Not just from the fact<br>
>> that because of the nature of the gate (2nd level virt on public clouds) the<br>
>> variability between jobs can be staggering. I can't imagine what value there is<br>
>> in running synthetic benchmarks in this environment. It would only reliably<br>
>> catch the most egregious of regressions. Also from what I can tell none of these<br>
>> jobs actually compare the timing data to the previous results, it just generates<br>
>> the data and makes a pretty graph. The burden appears to be on the user to<br>
>> figure out what it means, which really isn't that useful. How have these jobs<br>
>> actually helped? IMO the real value in performance testing in the gate is to<br>
>> capture the longer term trends in the data. Which is something these jobs are<br>
>> not doing.<br>
><br>
><br>
> So I put in a change to dump out the raw data from each run into a<br>
> zipped json file so that I can start looking at the value of<br>
> collecting this data.... As an experiment I think it is very worth<br>
> while. The gate job is none voting, and apparently, at least on the<br>
> cinder front, highly reliable. The job runs fast enough it isn't<br>
> slowing the gate down - we aren't running out of nodes on the gate as<br>
> far as I can tell, so I don't understand the hostility towards it.<br>
> We'll run it for a bit, see if it proves useful, if it doesn't then we<br>
> can turn it off and try something else.<br>
><br>
> I'm confused by the hostility about this gate job - it is costing us<br>
> nothing, if it turns out to be a pain we'll turn it off.<br>
<br>
</div>So aside from longer term issues that have already been brought up, as a short<br>
term experiment I agree it's probably fine. However, the argument that it costs<br>
us nothing isn't exactly the case. During the course of a day we routinely<br>
exhaust the max quota on nodes. Adding additional dsvm jobs just contributes to<br>
this exhaustion. While this probably isn't very noticeable when the gate is in a<br>
healthy state. (it just makes things a bit slower) However, when things aren't<br>
working this becomes a huge problem, because node churn slows down our ability<br>
to land fixes which just makes recovery slower. Given that we have a finite<br>
number of gate resources I don't really think we should be running something<br>
that's considered an experiment on every patch. Instead it should be in the<br>
experimental pipeline for the project so it can be run on-demand, but doesn't<br>
constantly eat resources.<br>
<div class=""><br>
><br>
> Rally as a general tool has enabled me do do things that I wouldn't<br>
> even consider trying with tempest. There shouldn't be a problem with a<br>
> small number of parallel efforts - that's a founding principle of<br>
> opensource in general.<br>
<br>
</div>So, I agree there is nothing wrong with doing things as a separate tool in a<br>
parallel effort, which was Thierry's option #3 on the original post. The<br>
question up for debate is whether we should adopt Rally into the QA program or<br>
create a new program for it. My opinion on the matter, for the reasons I've<br>
already outlined in my other posts, is no, not in it's current form. I'd really<br>
like to see collaboration here working towards eventual integration of Rally<br>
into the QA program. But, I don't think there is anything wrong with the rally<br>
dev team deciding to continue as they are outside of an OpenStack program.<br>
<br>
-Matt Treinish<br>
<br>
[1] <a href="http://docs.openstack.org/developer/tempest/field_guide/stress.html#stress-field-guide" target="_blank">http://docs.openstack.org/developer/tempest/field_guide/stress.html#stress-field-guide</a><br>
[2] <a href="http://git.openstack.org/cgit/openstack/tempest/tree/tempest/stress/etc/sample-unit-test.json" target="_blank">http://git.openstack.org/cgit/openstack/tempest/tree/tempest/stress/etc/sample-unit-test.json</a><br>

[3] <a href="http://specs.openstack.org/openstack/qa-specs/specs/tempest-library.html" target="_blank">http://specs.openstack.org/openstack/qa-specs/specs/tempest-library.html</a><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>
<br></blockquote></div><br></div>