<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 13, 2014 at 2:48 PM, Duncan Thomas <span dir="ltr"><<a href="mailto:duncan.thomas@gmail.com" target="_blank">duncan.thomas@gmail.com</a>></span> wrote:<br>

<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"><div class="">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>
</div><div class="">>> 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>
</div>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>
<div class=""><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>
</div>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>
<div><div class="h5"><br>
>> Matt, Sean - seriously community is about convincing people, not about<br>
>> forcing people to do something against their wiliness.  You are making huge<br>
>> architectural decisions without deep knowledge about what is Rally, what<br>
>> are use cases, road map, goals and auditory.<br>
>><br>
>> IMHO community in my opinion is thing about convincing people. So QA<br>
>> program should convince Rally team (at least me) to do such changes. Key<br>
>> secret to convince me, is to say how this will help OpenStack to perform<br>
>> better.<br>
><br>
> If community, per your definition, is about convincing people then there needs<br>
> to be a 2-way discussion. This is an especially key point considering the<br>
> feedback on this thread is basically the same feedback you've been getting since<br>
> you first announced Rally on the ML. [1] (and from even before that I think, but<br>
> it's hard to remember all the details from that far back)  I'm afraid that<br>
> without a shared willingness to explore what we're suggesting because of<br>
> preconceived notions then I fail to see the point in moving forward. The fact<br>
> that this feedback has been ignored is why this discussion has come up at all.<br>
><br>
>><br>
>> Currently Rally team see a lot of issues related to this decision:<br>
>><br>
>> 1) It breaks already existing performance jobs (Heat, Glance, Cinder,<br>
>> Neutron, Keystone)<br>
><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>
</div></div>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></blockquote><div><br></div><div>We actually run out of nodes almost every day now (except weekends), we have about 800 nodes, and hit that quota most days [0][1].</div><div><br>

</div><div>While the output of the rally job [2] is very impressive, with our constrained number of nodes, I am still struggling to grok the value of running this job on every patch. </div><div><br></div><div>[0] <a href="http://graphite.openstack.org/render/?from=-24hours&height=180&until=now&width=334&bgcolor=ffffff&fgcolor=000000&areaMode=stacked&target=color(alias(sumSeries(stats.gauges.nodepool.target.building),%20%27Building%27),%20%27ffbf52%27)&target=color(alias(sumSeries(stats.gauges.nodepool.target.ready),%20%27Available%27),%20%2700c868%27)&target=color(alias(sumSeries(stats.gauges.nodepool.target.used),%20%27In%20Use%27),%20%276464ff%27)&target=color(alias(sumSeries(stats.gauges.nodepool.target.delete),%20%27Deleting%27),%20%27c864ff%27)&title=Test%20Nodes&_t=0.8509290898218751#1407982412165">http://graphite.openstack.org/render/?from=-24hours&height=180&until=now&width=334&bgcolor=ffffff&fgcolor=000000&areaMode=stacked&target=color(alias(sumSeries(stats.gauges.nodepool.target.building),%20%27Building%27),%20%27ffbf52%27)&target=color(alias(sumSeries(stats.gauges.nodepool.target.ready),%20%27Available%27),%20%2700c868%27)&target=color(alias(sumSeries(stats.gauges.nodepool.target.used),%20%27In%20Use%27),%20%276464ff%27)&target=color(alias(sumSeries(stats.gauges.nodepool.target.delete),%20%27Deleting%27),%20%27c864ff%27)&title=Test%20Nodes&_t=0.8509290898218751#1407982412165</a></div>

<div><br></div><div>[1] <a href="http://graphite.openstack.org/render/?from=-12days&height=180&until=now&width=334&bgcolor=ffffff&fgcolor=000000&areaMode=stacked&target=color(alias(sumSeries(stats.gauges.nodepool.target.building),%20%27Building%27),%20%27ffbf52%27)&target=color(alias(sumSeries(stats.gauges.nodepool.target.ready),%20%27Available%27),%20%2700c868%27)&target=color(alias(sumSeries(stats.gauges.nodepool.target.used),%20%27In%20Use%27),%20%276464ff%27)&target=color(alias(sumSeries(stats.gauges.nodepool.target.delete),%20%27Deleting%27),%20%27c864ff%27)&title=Test%20Nodes&_t=0.8509290898218751#1407982412165">http://graphite.openstack.org/render/?from=-12days&height=180&until=now&width=334&bgcolor=ffffff&fgcolor=000000&areaMode=stacked&target=color(alias(sumSeries(stats.gauges.nodepool.target.building),%20%27Building%27),%20%27ffbf52%27)&target=color(alias(sumSeries(stats.gauges.nodepool.target.ready),%20%27Available%27),%20%2700c868%27)&target=color(alias(sumSeries(stats.gauges.nodepool.target.used),%20%27In%20Use%27),%20%276464ff%27)&target=color(alias(sumSeries(stats.gauges.nodepool.target.delete),%20%27Deleting%27),%20%27c864ff%27)&title=Test%20Nodes&_t=0.8509290898218751#1407982412165</a></div>

<div> </div><div><br></div><div>[2] <a href="http://logs.openstack.org/02/109202/4/check/gate-rally-dsvm-cinder/bbc256b/rally-plot/results.html.gz">http://logs.openstack.org/02/109202/4/check/gate-rally-dsvm-cinder/bbc256b/rally-plot/results.html.gz</a></div>

<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">
<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>
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>
<div class=""><div class="h5"><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>
</div></div></blockquote></div><br></div></div>