On Thu, Aug 7, 2014 at 6:20 AM, Sean Dague <s...@dague.net> wrote:

> On 08/07/2014 07:58 AM, Angus Salkeld wrote:
> > On Wed, 2014-08-06 at 15:48 -0600, John Griffith wrote:
> >> I have to agree with Duncan here.  I also don't know if I fully
> >> understand the limit in options.  Stress test seems like it
> >> could/should be different (again overlap isn't a horrible thing) and I
> >> don't see it as siphoning off resources so not sure of the issue.
> >>  We've become quite wrapped up in projects, programs and the like
> >> lately and it seems to hinder forward progress more than anything
> >> else.
> > h
> >>
> >> I'm also not convinced that Tempest is where all things belong, in
> >> fact I've been thinking more and more that a good bit of what Tempest
> >> does today should fall more on the responsibility of the projects
> >> themselves.  For example functional testing of features etc, ideally
> >> I'd love to have more of that fall on the projects and their
> >> respective teams.  That might even be something as simple to start as
> >> saying "if you contribute a new feature, you have to also provide a
> >> link to a contribution to the Tempest test-suite that checks it".
> >>  Sort of like we do for unit tests, cross-project tracking is
> >> difficult of course, but it's a start.  The other idea is maybe
> >> functional test harnesses live in their respective projects.
> >>
> >
> > Couldn't we reduce the scope of tempest (and rally) : make tempest the
> > API verification and rally the secenario/performance tester? Make each
> > tool do less, but better. My point being to split the projects by
> > functionality so there is less need to share code and stomp on each
> > other's toes.
>
> Who is going to propose the split? Who is going to manage the
> coordination of the split? What happens when their is disagreement about
> the location of something like booting and listing a server -
>
> https://github.com/stackforge/rally/blob/master/rally/benchmark/scenarios/nova/servers.py#L44-L64
>
> Because today we've got fundamental disagreements between the teams on
> scope, long standing (as seen in these threads), so this won't
> organically solve itself.
>
>         -Sean
>
> --
> Sean Dague
> http://dague.net
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
‚Äč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.

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.

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).

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.

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?

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?).
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to