___
> From: Geoffrey Anderson [ge...@confluent.io]
> Sent: Monday, June 08, 2015 10:56 PM
> To: dev@kafka.apache.org
> Subject: Re: [DISCUSS] KIP-25 System test improvements
>
> Hi KIP-25 thread,
>
> I consolidated some of the questions from this thread and elsewhere.
>
: Monday, June 08, 2015 10:56 PM
To: dev@kafka.apache.org
Subject: Re: [DISCUSS] KIP-25 System test improvements
Hi KIP-25 thread,
I consolidated some of the questions from this thread and elsewhere.
Q: Can we see a map of what system-test currently tests, which ones we want
to replace and JIRAs for
Hi KIP-25 thread,
I consolidated some of the questions from this thread and elsewhere.
Q: Can we see a map of what system-test currently tests, which ones we want
to replace and JIRAs for replacing?
A: Initial draft here:
https://cwiki.apache.org/confluence/display/KAFKA/Roadmap+-+port+existing+s
Hi Gwen,
I don't see any problem with this as long as we're convinced there's a good
use case, which seems to be true.
Cheers,
Geoff
On Thu, Jun 4, 2015 at 5:20 PM, Gwen Shapira wrote:
> Not completely random places :)
> People may use Cloudera / HWX distributions which include Kafka, but want
Not completely random places :)
People may use Cloudera / HWX distributions which include Kafka, but want
to verify that these bits match a specific upstream release.
I think having the tests separately will be useful for this. In this case,
finding the tests are not a big issue - we'll add a down
Hey Gwen,
Currently the test and code are downloaded at the same time. Supposedly
the tests in the same repository should cover match the code.
Are you saying people downloaded a release from some random place and want
to verify it? If that is the case, does that mean people still need to
find the
Hi,
Reviving the discussion a bit :)
I think it will be nice if each Kafka version that we release will also
have a separate "tests" artifact that users can download, untar and easily
run against a Kafka cluster of the same version.
The idea is that if someone downloads packages that claim to co
Hi Ashish,
Looks like Ewen already hit the main points, but a few additions:
1. ducktape repo is here: https://github.com/confluentinc/ducktape
ducktape itself will be pip installable in the near future, and Kafka
system tests will be able to depend on a particular version of ducktape.
2. The r
Ashish,
1. That was the plan. We put some effort into cleanly separating the
framework so it would be reusable across many projects.
2. I think you're seeing a test in progress where the final report hasn't
been created yet. If you visit one of the older ones you'll see it has a
landing page with
Geoffrey,
This looks great!
A few questions.
1. Will ducktape be maintained separately as a github repo?
2. How easy is viewing the test results and logs. The link in KIP,
http://testing.confluent.io/confluent_platform/latest/, lists a bunch of
files and dirs. Could you add to KIP how the result
Great, I'll work on putting together a more detailed map of this
replacement process.
On Thu, May 21, 2015 at 11:13 AM, Gwen Shapira
wrote:
> Love this idea :)
>
> I took a look at Ducktape API and it looks like a good fit - clean API,
> extensible, easy to use and powerful enough for our use-ca
Love this idea :)
I took a look at Ducktape API and it looks like a good fit - clean API,
extensible, easy to use and powerful enough for our use-case.
Something I'd like to see as part of the KIP is a map of what system-test
currently tests, which ones we want to replace and a JIRA for replacing
12 matches
Mail list logo
