On Thu, Aug 7, 2014 at 9:02 AM, John Griffith <john.griff...@solidfire.com>

> 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?).
> ​Just a note, I don't mean for the above to point fingers or even remotely
suggest that I think I have all the answers etc.  I just would like to spur
some serious thought on how we scale and grow going forward and that
includes Tempest and it role.

Currently I have zero complaints (really... zero) about Tempest, the QA or
Infra teams.  I do see more snags like the one we currently have in our
future though, and I think we need to come up with some way of adapting and
of course collaborating better and more easily.​  I also do have concerns
WRT scale in the future.

OpenStack-dev mailing list

Reply via email to