<div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 7, 2014 at 6:20 AM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</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 08/07/2014 07:58 AM, Angus Salkeld wrote:<br>
> On Wed, 2014-08-06 at 15:48 -0600, John Griffith wrote:<br>
>> I have to agree with Duncan here. I also don't know if I fully<br>
>> understand the limit in options. Stress test seems like it<br>
>> could/should be different (again overlap isn't a horrible thing) and I<br>
>> don't see it as siphoning off resources so not sure of the issue.<br>
>> We've become quite wrapped up in projects, programs and the like<br>
>> lately and it seems to hinder forward progress more than anything<br>
>> else.<br>
> h<br>
>><br>
>> I'm also not convinced that Tempest is where all things belong, in<br>
>> fact I've been thinking more and more that a good bit of what Tempest<br>
>> does today should fall more on the responsibility of the projects<br>
>> themselves. For example functional testing of features etc, ideally<br>
>> I'd love to have more of that fall on the projects and their<br>
>> respective teams. That might even be something as simple to start as<br>
>> saying "if you contribute a new feature, you have to also provide a<br>
>> link to a contribution to the Tempest test-suite that checks it".<br>
>> Sort of like we do for unit tests, cross-project tracking is<br>
>> difficult of course, but it's a start. The other idea is maybe<br>
>> functional test harnesses live in their respective projects.<br>
>><br>
><br>
> Couldn't we reduce the scope of tempest (and rally) : make tempest the<br>
> API verification and rally the secenario/performance tester? Make each<br>
> tool do less, but better. My point being to split the projects by<br>
> functionality so there is less need to share code and stomp on each<br>
> other's toes.<br>
<br>
</div></div>Who is going to propose the split? Who is going to manage the<br>
coordination of the split? What happens when their is disagreement about<br>
the location of something like booting and listing a server -<br>
<a href="https://github.com/stackforge/rally/blob/master/rally/benchmark/scenarios/nova/servers.py#L44-L64" target="_blank">https://github.com/stackforge/rally/blob/master/rally/benchmark/scenarios/nova/servers.py#L44-L64</a><br>
<br>
Because today we've got fundamental disagreements between the teams on<br>
scope, long standing (as seen in these threads), so this won't<br>
organically solve itself.<br>
<div class="HOEnZb"><div class="h5"><br>
-Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" target="_blank">http://dague.net</a><br>
<br>
</div></div><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><div class="gmail_extra"><div class="gmail_default" style="font-family:'courier new',monospace">last paragraph regarding the "split" wasn't mine, but... I think it's good for people to express ideas on the ML like this. It may not be feasible, but I think the more people you have thinking about how to move forward and expressing their ideas (even if they don't work) is a good and healthy thing.</div>
<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">As far as proposing a split, there's obviously a ton of detail that needs to be considered here and honestly it may just be a horrible idea right from the start. That being said, to answer some of your questions, quite honestly IMO these are some of the things that I think it would be good for the TC to take an active role in. Seems reasonable to have bodies like the TC work on governing and laying out technical process and direction.</div>
<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">Anyway, I think the bottom line is that better collaboration is something we need to work on. That in and of itself would've have likely thwarted this this thread to begin with (and I think that was one of the key points it tried to make). </div>
<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">As far as the question at hand of Rally... I would surely hope that there's a way to for QA and Rally teams to actually collaborate and work together on this. I also understand completely that lack of collaboration is probably what got us to this point in the first place. It just seems to me that there's a middle ground somewhere but it's going to require some give and take from both sides. </div>
<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">By the way, personally I feel that the movement over the last year that everybody needs to have their own program or project is a big problem. The other thing that nobody wants to consider is why not just put some code on github independent of OpenStack? Contribute things to the projects and build cool things for OpenStack outside of OpenStack. Make sense?</div>
<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">Questions about functional test responsibilities for projects etc should probably be a future discussion if there's interest and if it makes any sense at all (ie summit topic?).</div>
<br></div></div>