<div dir="ltr"><div><font face="arial, sans-serif">Marc, </font></div><span style="font-family:arial,sans-serif;font-size:13px"><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div></span><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">A good example for that is Rally's Tempest configuration module. Currently<br></span><span style="font-family:arial,sans-serif;font-size:13px">Rally has all the logic to configure Tempest and for that you have your<br>
</span><span style="font-family:arial,sans-serif;font-size:13px">own way to build the tempest conf out of a template [1]. If the QA<br></span><span style="font-family:arial,sans-serif;font-size:13px">team decides to rework the configuration Rally is broken.</span></blockquote>
<div><br></div><div>Absolutely agree with this point. That is why we are working on: </div><div><a href="https://review.openstack.org/#/c/94473/">https://review.openstack.org/#/c/94473/</a> that adds this feature to Tempest,</div>
<div>when this will be implemented we will remove tempest configuration from Rally. <br></div><div><br></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">
<span style="font-family:arial,sans-serif;font-size:13px">IMHO rally duplicates at least some pieces. So you can find parts of<br></span><span style="font-family:arial,sans-serif;font-size:13px">Tempest scenarios tests in the benchmarks area, Tempest stress tests<br>
</span><span style="font-family:arial,sans-serif;font-size:13px">and Tempest config.</span></blockquote><div><br></div><div>Yep agree there is similar functionality in Rally & Tempest about load generation: </div><div>
1) tempest: <a href="https://github.com/openstack/tempest/tree/master/tempest/stress">https://github.com/openstack/tempest/tree/master/tempest/stress</a></div><div>2) rally: <a href="https://github.com/stackforge/rally/tree/master/rally/benchmark/scenarios/tempest">https://github.com/stackforge/rally/tree/master/rally/benchmark/scenarios/tempest</a></div>
<div><br></div><div>But seems like Rally has more common load generator that can use both Tempest & Rally scenarios. </div><div>Maybe it makes sense to keep only one solution for this? </div><div><br></div><div><br></div>
<div><br></div><div>Best regards,</div><div>Boris Pavlovic </div><div><br></div><div><br></div><div> </div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 5, 2014 at 10:38 AM,  <span dir="ltr"><<a href="mailto:marc@koderer.com" target="_blank">marc@koderer.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello Boris,<br>
<br>
see below.<br>
<br>
Zitat von Boris Pavlovic <<a href="mailto:boris@pavlovic.me" target="_blank">boris@pavlovic.me</a>>:<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Jay,<br>
<br>
Thanks for review of proposal. Some my comments below..<br>
<br>
<br>
I think this is one of the roots of the problem that folks like David<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
and Sean keep coming around to. If Rally were less monolithic, it<br>
would be easier to say "OK, bring this piece into Tempest, have this<br>
piece be a separate library and live in the QA program, and have the<br>
service endpoint that allows operators to store and periodically measure<br>
SLA performance indicators against their cloud."<br>
</blockquote>
<br>
Actually Rally was designed to be a glue service (and cli tool) that will<br>
bind everything together and present service endpoint for Operators. I<br>
really do not understand what can be split? and put to tempest? and<br>
actually why? Could you elaborate pointing on current Rally code, maybe<br>
there is some misleading here. I think this should be discussed in more<br>
details..<br>
<br>
</blockquote>
<br></div>
A good example for that is Rally's Tempest configuration module. Currently<br>
Rally has all the logic to configure Tempest and for that you have your<br>
own way to build the tempest conf out of a template [1]. If the QA<br>
team decides to rework the configuration Rally is broken.<br>
<br>
[1]: <a href="https://github.com/stackforge/rally/blob/master/rally/verification/verifiers/tempest/config.ini" target="_blank">https://github.com/stackforge/<u></u>rally/blob/master/rally/<u></u>verification/verifiers/<u></u>tempest/config.ini</a><br>

<br>
<br>
[snip]<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I found the Scalr incubation discussion:<br>
<a href="http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-06-14-20.03.log.html" target="_blank">http://eavesdrop.openstack.<u></u>org/meetings/openstack-<u></u>meeting/2011/openstack-<u></u>meeting.2011-06-14-20.03.log.<u></u>html</a><br>

<br>
The reasons of reject were next:<br>
*) OpenStack shouldn't put PaaS in OpenStack core # rally is not PaaS<br>
*) Duplication of functionality (actually dashboard)  # Rally doesn't<br>
duplicate anything<br>
</blockquote>
<br></div>
IMHO rally duplicates at least some pieces. So you can find parts of<br>
Tempest scenarios tests in the benchmarks area, Tempest stress tests<br>
and Tempest config.<br>
<br>
<br>
Regards<br>
Marc<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
*) Development is done behind closed doors<br>
# Not about Rally<br>
<a href="http://stackalytics.com/?release=juno&metric=commits&project_type=All&module=rally" target="_blank">http://stackalytics.com/?<u></u>release=juno&metric=commits&<u></u>project_type=All&module=rally</a><br>

<br>
Seems like Rally is quite different case and this comparison is misleading<br>
& irrelevant to current case.<br>
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
, that is why I think Rally should be a separated program (i.e.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Rally scope is just different from QA scope). As well, It's not clear<br>
for me, why collaboration is possible only in case of one program? In<br>
my opinion collaboration & programs are irrelevant things.<br>
</blockquote>
<br>
<br>
Sure, it's certainly possible for collaboration to happen across<br>
programs. I think what Sean is alluding to is the fact that the Tempest<br>
and Rally communities have done little collaboration to date, and that<br>
is worrying to him.<br>
</blockquote>
<br>
<br>
Could you please explain this paragraph. What do you mean by "have done<br>
little collaboration"<br>
<br>
We integrated Tempest in Rally:<br>
<a href="http://www.mirantis.com/blog/rally-openstack-tempest-testing-made-simpler/" target="_blank">http://www.mirantis.com/blog/<u></u>rally-openstack-tempest-<u></u>testing-made-simpler/</a><br>
<br>
We are working on spec in Tempest about tempest conf generation:<br>
<a href="https://review.openstack.org/#/c/94473/" target="_blank">https://review.openstack.org/#<u></u>/c/94473/</a> # probably not so fast as we would<br>
like<br>
<br>
We had design session:<br>
<a href="http://junodesignsummit.sched.org/event/2815ca60f70466197d3a81d62e1ee7e4#.U9_ugYCSz1g" target="_blank">http://junodesignsummit.sched.<u></u>org/event/<u></u>2815ca60f70466197d3a81d62e1ee7<u></u>e4#.U9_ugYCSz1g</a><br>

<br>
I am going to work on integration OSprofiler in tempest, as soon as I get<br>
it in core projects.<br>
<br>
By the way, I am really not sure how being one Program will help us to<br>
collaborate? What it actually changes?<br>
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
About collaboration between Rally & Tempest teams... Major goal of<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
integration Tempest in Rally is to make it simpler to use tempest on<br>
production clouds via OpenStack API.<br>
</blockquote>
<br>
<br>
</blockquote>
Plenty of folks run Tempest without Rally against production clouds as<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
an acceptance test platform. I see no real benefit to arguing that Rally<br>
is for running against production clouds and Tempest is for<br>
non-production clouds. There just isn't much of a difference there.<br>
</blockquote>
<br>
<br>
Hm, I didn't say anything about "Tempest is for non-prduction clouds"...<br>
I said that Rally team is working on making it simpler to use on production<br>
clouds..<br>
<br>
<br>
<br>
The problem I see is that Rally is not *yet* exposing the REST service<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
endpoint that would make it a full-fledged Operator Tool outside the<br>
scope of its current QA focus. Once Rally does indeed publish a REST API<br>
that exposes resource endpoints for an operator to store a set of KPIs<br>
associated with an SLA, and allows the operator to store the run<br>
schedule that Rally would use to go and test such metrics, *then* would<br>
be the appropriate time to suggest that Rally be the pilot project in<br>
this new Operator Tools program, IMO.<br>
</blockquote>
<br>
<br>
It's really almost done.. It is all about 2 weeks of work...<br>
<br>
<br>
<br>
I'm sure all of those things would be welcome additions to Tempest. At the<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
same time, Rally contributors would do well to work on an initial REST API<br>
endpoint that would expose the resources I denoted above.<br>
</blockquote>
<br>
<br>
As I said before it's almost finished..<br>
<br>
<br>
Best regards,<br>
Boris Pavlovic<br>
<br>
<br>
<br>
On Mon, Aug 4, 2014 at 8:25 PM, Jay Pipes <<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 08/04/2014 11:21 AM, Boris Pavlovic wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Rally is quite monolithic and can't be split<br>
<br>
</blockquote>
<br>
I think this is one of the roots of the problem that folks like David<br>
and Sean keep coming around to. If Rally were less monolithic, it<br>
would be easier to say "OK, bring this piece into Tempest, have this<br>
piece be a separate library and live in the QA program, and have the<br>
service endpoint that allows operators to store and periodically measure<br>
SLA performance indicators against their cloud."<br>
<br>
Incidentally, this is one of the problems that Scalr faced when applying<br>
for incubation, years ago, and one of the reasons the PPB at the time voted<br>
not to incubate Scalr: it had a monolithic design that crossed too many<br>
different lines in terms of duplicating functionality that already existed<br>
in a number of other projects.<br>
<br>
<br>
 , that is why I think Rally should be a separated program (i.e.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Rally scope is just different from QA scope). As well, It's not clear<br>
for me, why collaboration is possible only in case of one program? In<br>
my opinion collaboration & programs are irrelevant things.<br>
<br>
</blockquote>
<br>
Sure, it's certainly possible for collaboration to happen across<br>
programs. I think what Sean is alluding to is the fact that the Tempest<br>
and Rally communities have done little collaboration to date, and that<br>
is worrying to him.<br>
<br>
<br>
 About collaboration between Rally & Tempest teams... Major goal of<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
integration Tempest in Rally is to make it simpler to use tempest on<br>
production clouds via OpenStack API.<br>
<br>
</blockquote>
<br>
Plenty of folks run Tempest without Rally against production clouds as<br>
an acceptance test platform. I see no real benefit to arguing that Rally<br>
is for running against production clouds and Tempest is for<br>
non-production clouds. There just isn't much of a difference there.<br>
<br>
That said, an Operator Tools program is actually an entirely different<br>
concept -- with a different audience and mission from the QA program. I<br>
think you've seen here some initial support for such a proposed Operator<br>
Tools program.<br>
<br>
The problem I see is that Rally is not *yet* exposing the REST service<br>
endpoint that would make it a full-fledged Operator Tool outside the<br>
scope of its current QA focus. Once Rally does indeed publish a REST API<br>
that exposes resource endpoints for an operator to store a set of KPIs<br>
associated with an SLA, and allows the operator to store the run<br>
schedule that Rally would use to go and test such metrics, *then* would<br>
be the appropriate time to suggest that Rally be the pilot project in<br>
this new Operator Tools program, IMO.<br>
<br>
<br>
 This work requires a lot of collaboration between teams, as you<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
already mention we should work on improving measuring durations and<br>
tempest.conf generation. I fully agree that this belongs to Tempest.<br>
By the way, Rally team is already helping with this part.<br>
<br>
In my opinion, end result should be something like: Rally just calls<br>
Tempest (or couple of scripts from tempest) and store results to its<br>
DB, presenting to end user tempest functionality via OpenStack API.<br>
To get this done, we should implement next features in tempest: 1)<br>
Auto  tempest.conf generation 2) Production ready cleanup  - tempest<br>
should be absolutely safe for run against cloud 3) Improvements<br>
related to time measurement. 4) Integration of OSprofiler & Tempest.<br>
<br>
</blockquote>
<br>
I'm sure all of those things would be welcome additions to Tempest. At the<br>
same time, Rally contributors would do well to work on an initial REST API<br>
endpoint that would expose the resources I denoted above.<br>
<br>
Best,<br>
-jay<br>
<br>
 So in any case I would prefer to continue collaboration..<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thoughts?<br>
<br>
<br>
Best regards, Boris Pavlovic<br>
<br>
<br>
<br>
<br>
On Mon, Aug 4, 2014 at 4:24 PM, Sean Dague <<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a><br>
<mailto:<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>>> wrote:<br>
<br>
On 07/31/2014 06:55 AM, Angus Salkeld wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Sun, 2014-07-27 at 07:57 -0700, Sean Dague wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 07/26/2014 05:51 PM, Hayes, Graham wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tue, 2014-07-22 at 12:18 -0400, Sean Dague wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 07/22/2014 11:58 AM, David Kranz wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 07/22/2014 10:44 AM, Sean Dague wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Honestly, I'm really not sure I see this as a different<br>
<br>
</blockquote>
program, but is<br>
</blockquote></blockquote></blockquote></blockquote></blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
really something that should be folded into the QA<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
program.<br>
<br>
</blockquote>
I feel like<br>
</blockquote></blockquote></blockquote></blockquote></blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
a top level effort like this is going to lead to a lot<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
of<br>
<br>
</blockquote>
duplication in<br>
</blockquote></blockquote></blockquote></blockquote></blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
the data analysis that's currently going on, as well as<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
</blockquote>
functionality<br>
</blockquote></blockquote></blockquote></blockquote></blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
for better load driver UX.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-Sean<br>
<br>
</blockquote>
+1 It will also lead to pointless discussions/arguments<br>
about which activities are part of "QA" and which are part<br>
of "Performance and Scalability Testing".<br>
<br>
</blockquote>
<br>
</blockquote>
I think that those discussions will still take place, it will<br>
<br>
</blockquote>
just be on<br>
</blockquote></blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
a per repository basis, instead of a per program one.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
[snip]<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Right, 100% agreed. Rally would remain with it's own repo +<br>
<br>
</blockquote>
review team,<br>
</blockquote></blockquote></blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
just like grenade.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
-Sean<br>
<br>
<br>
</blockquote>
Is the concept of a separate review team not the point of a<br>
<br>
</blockquote>
program?<br>
</blockquote></blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In the the thread from Designate's Incubation request Thierry<br>
<br>
</blockquote>
said [1]:<br>
</blockquote></blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 "Programs" just let us bless goals and teams and let them<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
organize code however they want, with contribution to any<br>
code repo<br>
<br>
</blockquote>
under that<br>
</blockquote></blockquote></blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
umbrella being considered "official" and<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

ATC-status-granting.<br>
<br>
</blockquote>
<br>
I do think that this is something that needs to be clarified<br>
by<br>
<br>
</blockquote>
the TC -<br>
</blockquote></blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Rally could not get a PTL if they were part of the QA project,<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
</blockquote>
but every<br>
</blockquote></blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
time we get a program request, the same discussion happens.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I think that mission statements can be edited to fit new<br>
<br>
</blockquote>
programs as<br>
</blockquote></blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
they occur, and that it is more important to let teams that<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
</blockquote>
have been<br>
</blockquote></blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
working closely together to stay as a distinct group.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
</blockquote>
<br>
My big concern here is that many of the things that these<br>
<br>
</blockquote>
efforts have<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
been doing are things we actually want much closer to the base.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For instance, metrics on Tempest runs.<br>
<br>
When Rally was first created it had it's own load generator. It<br>
<br>
</blockquote>
took a<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
ton of effort to keep the team from duplicating that and instead<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
</blockquote>
just<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
use some subset of Tempest. Then when measuring showed up, we<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
</blockquote>
actually<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
said that is something that would be great in Tempest, so<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
</blockquote>
whoever ran<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
it, be it for Testing, Monitoring, or Performance gathering,<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
</blockquote>
would have<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
access to that data. But the Rally team went off in a corner and<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
</blockquote>
did it<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
otherwise. That's caused the QA team to have to go and redo this<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
</blockquote>
work<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
from scratch with subunit2sql, in a way that can be consumed by<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
</blockquote>
multiple<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
efforts.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
So I'm generally -1 to this being a separate effort on the basis<br>
<br>
</blockquote>
that so<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
far the team has decided to stay in their own sandbox instead of<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 participating actively where many of us thing the functions<br>
<br>
</blockquote>
should be<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
added. I also think this isn't like Designate, because this isn't<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
intended to be part of the integrated release.<br>
<br>
</blockquote>
<br>
>From reading Boris's email it seems like rally will provide a<br>
horizon panel and api to back it (for the operator to kick of<br>
performance<br>
<br>
</blockquote>
runs<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
and view stats). So this does seem like something that would be a<br>
part of the integrated release (if I am reading things correctly).<br>
<br>
Is the QA program happy to extend their scope to include that? QA<br>
could become "Quality Assurance of upstream code and running<br>
OpenStack installations". If not we need to find some other program<br>
for rally.<br>
<br>
</blockquote>
<br>
I think that's realistically already the scope of the QA program, we<br>
 might just need to change the governance wording.<br>
<br>
Tempest has always been intended to be run on production clouds<br>
(public or private) to ensure proper function. Many operators are<br>
doing this today as part of normal health management. And we<br>
continue to evolve it to be something which works well in that<br>
environment.<br>
<br>
All the statistics collection / analysis parts in Rally today I think<br>
are basically things that should be part of any Tempest installation<br>
/ run. It's cool that Rally did a bunch of work there, but having<br>
that code outside of Tempest is sort of problematic, especially as<br>
there are huge issues with the collection of that data because of<br>
missing timing information in subunit. So realistically to get<br>
accurate results there needs to be additional events added into<br>
Tempest tests to build this correctly. If you stare at the raw<br>
results here today they have such huge accuracy problems (due to<br>
unaccounted for time in setupClass, which is a known problem) to the<br>
point of being misleading, and possibly actually harmful.<br>
<br>
These are things that are fixable, but hard to do outside of the<br>
Tempest project itself. Exporting accurate timing / stats should be<br>
a feature close to the test load, not something that's done<br>
externally with guessing and fudge factors.<br>
<br>
So every time I look at the docs in Rally -<br>
<a href="https://github.com/stackforge/rally" target="_blank">https://github.com/stackforge/<u></u>rally</a> I see largely features that<br>
should be coming out of the test runners themselves.<br>
<br>
-Sean<br>
<br>
-- Sean Dague <a href="http://dague.net" target="_blank">http://dague.net</a><br>
<br>
<br>
______________________________<u></u>_________________ OpenStack-dev<br>
mailing list <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<mailto:<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.<u></u>openstack.org</a>><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
<br>
<br>
<br>
<br>
<br>
______________________________<u></u>_________________ OpenStack-dev<br>
mailing list <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
<br>
<br>
</blockquote>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
<br>
</blockquote></blockquote>
<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br></div>