<div dir="ltr">Jay,<div><br></div><div>Thanks for review of proposal. Some my comments below..</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">I think this is one of the roots of the problem that folks like David<br></span><span style="font-family:arial,sans-serif;font-size:13px">and Sean keep coming around to. If Rally were less monolithic, it<br>
</span><span style="font-family:arial,sans-serif;font-size:13px">would be easier to say "OK, bring this piece into Tempest, have this<br></span><span style="font-family:arial,sans-serif;font-size:13px">piece be a separate library and live in the QA program, and have the service endpoint that allows operators to store and periodically measure SLA performance indicators against their cloud."</span></blockquote>
<div><br></div><div><br></div><div>Actually Rally was designed to be a glue service (and cli tool) that will bind everything together and present service endpoint for Operators. I really do not understand what can be split? and put to tempest? and actually why? Could you elaborate pointing on current Rally code, maybe there is some misleading here. I think this should be discussed in more details..</div>
<div><br></div><div>By the way I believe that monolithic architecture is the best one, like Linus does.=)</div><div><a href="http://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_debate">http://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_debate</a><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">Incidentally, this is one of the problems that Scalr faced when applying for incubation, years ago, and one of the reasons the PPB at the time voted not to incubate Scalr: it had a monolithic design that crossed too many different lines in terms of duplicating functionality that already existed in a number of other projects.</span></blockquote>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><font face="arial, sans-serif">I found the Scalr incubation discussion: </font></div><div><font face="arial, sans-serif"><a href="http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-06-14-20.03.log.html">http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-06-14-20.03.log.html</a></font><br>
</div><div><font face="arial, sans-serif"><br></font></div><div>The reasons of reject were next: </div><div>*) OpenStack shouldn't put PaaS in OpenStack core # rally is not PaaS</div><div>*) Duplication of functionality (actually dashboard)  # Rally doesn't duplicate anything </div>
<div>*) Development is done behind closed doors </div><div># Not about Rally <a href="http://stackalytics.com/?release=juno&metric=commits&project_type=All&module=rally">http://stackalytics.com/?release=juno&metric=commits&project_type=All&module=rally</a></div>
<div><br></div><div>Seems like Rally is quite different case and this comparison is misleading & irrelevant to current case. </div><div><br></div><div><br></div><div><div class="im" style="font-family:arial,sans-serif;font-size:13px">
<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 class=""><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">
, that is why I think Rally should be a separated program (i.e.<br>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.</blockquote>
</blockquote><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><span style="font-family:arial,sans-serif;font-size:13px">Sure, it's certainly possible for collaboration to happen across<br>
</span><span style="font-family:arial,sans-serif;font-size:13px">programs. I think what Sean is alluding to is the fact that the Tempest<br></span><span style="font-family:arial,sans-serif;font-size:13px">and Rally communities have done little collaboration to date, and that<br>
</span><span style="font-family:arial,sans-serif;font-size:13px">is worrying to him.</span></blockquote></div></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div>Could you please explain this paragraph. What do you mean by "have done little collaboration"</div>
<div><br></div><div>We integrated Tempest in Rally:</div><div><a href="http://www.mirantis.com/blog/rally-openstack-tempest-testing-made-simpler/">http://www.mirantis.com/blog/rally-openstack-tempest-testing-made-simpler/</a><br>
</div><div><br></div><div>We are working on spec in Tempest about tempest conf generation: </div><div><a href="https://review.openstack.org/#/c/94473/">https://review.openstack.org/#/c/94473/</a> # probably not so fast as we would like<br>
</div><div><br></div><div>We had design session:</div><div><a href="http://junodesignsummit.sched.org/event/2815ca60f70466197d3a81d62e1ee7e4#.U9_ugYCSz1g">http://junodesignsummit.sched.org/event/2815ca60f70466197d3a81d62e1ee7e4#.U9_ugYCSz1g</a><br>
</div><div><br></div><div>I am going to work on integration OSprofiler in tempest, as soon as I get it in core projects. </div><div><br></div><div>By the way, I am really not sure how being one Program will help us to collaborate? What it actually changes? </div>
<div><br></div><div><br></div><div><div class="im" style="font-family:arial,sans-serif;font-size:13px"><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 class=""><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">About collaboration between Rally & Tempest teams... Major goal of<br>
integration Tempest in Rally is to make it simpler to use tempest on<br>production clouds via OpenStack API.</blockquote></blockquote><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">Plenty of folks run Tempest without Rally against production clouds as<br></span><span style="font-family:arial,sans-serif;font-size:13px">an acceptance test platform. I see no real benefit to arguing that Rally<br>
</span><span style="font-family:arial,sans-serif;font-size:13px">is for running against production clouds and Tempest is for<br></span><span style="font-family:arial,sans-serif;font-size:13px">non-production clouds. There just isn't much of a difference there.</span></blockquote>
</div><div><br></div><div>Hm, I didn't say anything about "Tempest is for non-prduction clouds"...</div><div>I said that Rally team is working on making it simpler to use on production clouds..</div><div><br>
</div><div><br></div><div><br style="font-family:arial,sans-serif;font-size:13px"><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">The problem I see is that Rally is not *yet* exposing the REST service<br></span><span style="font-family:arial,sans-serif;font-size:13px">endpoint that would make it a full-fledged Operator Tool outside the<br>
</span><span style="font-family:arial,sans-serif;font-size:13px">scope of its current QA focus. Once Rally does indeed publish a REST API<br></span><span style="font-family:arial,sans-serif;font-size:13px">that exposes resource endpoints for an operator to store a set of KPIs<br>
</span><span style="font-family:arial,sans-serif;font-size:13px">associated with an SLA, and allows the operator to store the run<br></span><span style="font-family:arial,sans-serif;font-size:13px">schedule that Rally would use to go and test such metrics, *then* would<br>
</span><span style="font-family:arial,sans-serif;font-size:13px">be the appropriate time to suggest that Rally be the pilot project in<br></span><span style="font-family:arial,sans-serif;font-size:13px">this new Operator Tools program, IMO.</span></blockquote>
</div><div><br></div><div>It's really almost done.. It is all about 2 weeks of work...</div><div><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">I'm sure all of those things would be welcome additions to Tempest. At the same time, Rally contributors would do well to work on an initial REST API endpoint that would expose the resources I denoted above.</span></blockquote>
<div><br></div><div>As I said before it's almost finished.. </div><div><br></div><div><br></div><div>Best regards,</div><div>Boris Pavlovic </div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Mon, Aug 4, 2014 at 8:25 PM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">On 08/04/2014 11:21 AM, Boris Pavlovic wrote:<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>
</blockquote>
<br></div>
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 service endpoint that allows operators to store and periodically measure SLA performance indicators against their cloud."<br>
<br>
Incidentally, this is one of the problems that Scalr faced when applying for incubation, years ago, and one of the reasons the PPB at the time voted not to incubate Scalr: it had a monolithic design that crossed too many different lines in terms of duplicating functionality that already existed in a number of other projects.<div class="">
<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>
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></div>
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.<div class=""><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>
integration Tempest in Rally is to make it simpler to use tempest on<br>
production clouds via OpenStack API.<br>
</blockquote>
<br></div>
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.<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This work requires a lot of collaboration between teams, as you<br>
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>
</blockquote>
<br></div>
I'm sure all of those things would be welcome additions to Tempest. At the same time, Rally contributors would do well to work on an initial REST API endpoint that would expose the resources I denoted above.<br>
<br>
Best,<br>
-jay<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
So in any case I would prefer to continue collaboration..<br>
<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></div><div><div class="h5">
<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>
<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>
<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>
<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>
<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>
<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>
<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>
</blockquote></blockquote></blockquote></blockquote></blockquote></blockquote>
program, but is<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"><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>
program.<br>
</blockquote></blockquote></blockquote></blockquote></blockquote></blockquote>
I feel like<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"><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>
of<br>
</blockquote></blockquote></blockquote></blockquote></blockquote></blockquote>
duplication in<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"><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></blockquote></blockquote></blockquote></blockquote></blockquote>
functionality<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"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

for better load driver UX.<br>
<br>
-Sean<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>
</blockquote></blockquote>
<br>
I think that those discussions will still take place, it will<br>
</blockquote></blockquote></blockquote>
just be on<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">

a per repository basis, instead of a per program one.<br>
<br>
[snip]<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Right, 100% agreed. Rally would remain with it's own repo +<br>
</blockquote></blockquote></blockquote></blockquote>
review team,<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">
just like grenade.<br>
<br>
-Sean<br>
<br>
</blockquote>
<br>
Is the concept of a separate review team not the point of a<br>
</blockquote></blockquote></blockquote>
program?<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>
In the the thread from Designate's Incubation request Thierry<br>
</blockquote></blockquote></blockquote>
said [1]:<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>
<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>
organize code however they want, with contribution to any<br>
code repo<br>
</blockquote></blockquote></blockquote></blockquote>
under 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"><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">
umbrella being considered "official" and<br>
ATC-status-granting.<br>
</blockquote>
<br>
I do think that this is something that needs to be clarified<br>
by<br>
</blockquote></blockquote></blockquote>
the TC -<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">

Rally could not get a PTL if they were part of the QA project,<br>
</blockquote></blockquote></blockquote>
but every<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">

time we get a program request, the same discussion happens.<br>
<br>
I think that mission statements can be edited to fit new<br>
</blockquote></blockquote></blockquote>
programs 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">

they occur, and that it is more important to let teams that<br>
</blockquote></blockquote></blockquote>
have been<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">

working closely together to stay as a distinct group.<br>
</blockquote>
<br>
My big concern here is that many of the things that these<br>
</blockquote></blockquote>
efforts have<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">
been doing are things we actually want much closer to the base.<br>
For instance, metrics on Tempest runs.<br>
<br>
When Rally was first created it had it's own load generator. It<br>
</blockquote></blockquote>
took a<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">
ton of effort to keep the team from duplicating that and instead<br>
</blockquote></blockquote>
just<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">
use some subset of Tempest. Then when measuring showed up, we<br>
</blockquote></blockquote>
actually<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">
said that is something that would be great in Tempest, so<br>
</blockquote></blockquote>
whoever ran<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">
it, be it for Testing, Monitoring, or Performance gathering,<br>
</blockquote></blockquote>
would have<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">
access to that data. But the Rally team went off in a corner and<br>
</blockquote></blockquote>
did it<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">
otherwise. That's caused the QA team to have to go and redo this<br>
</blockquote></blockquote>
work<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">
from scratch with subunit2sql, in a way that can be consumed by<br>
</blockquote></blockquote>
multiple<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">
efforts.<br>
<br>
So I'm generally -1 to this being a separate effort on the basis<br>
</blockquote></blockquote>
that so<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">
far the team has decided to stay in their own sandbox instead of<br>
 participating actively where many of us thing the functions<br>
</blockquote></blockquote>
should be<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">
added. I also think this isn't like Designate, because this isn't<br>
intended to be part of the integrated release.<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>
</blockquote>
runs<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>
</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></div></div>
<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><div class=""><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>
</div></blockquote><div class="HOEnZb"><div class="h5">
<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>