[automated-testing] gluster-block: Discussion regarding glusto tests

[Nigel Babu]

>
>
>> Pranith/Prasanna: At the moment your problem is that you want to write
>> tests in conjunction with your pull request and splitting into multiple
>> repos do not give you this ability. Is that the compelling reason why you
>> want this to happen in the gluster-block repo directly rather than
>> glusto-tests?
>>
>
> Yes. Goal is to be able to test HEAD with tests at HEAD, write tests once
> and be done. It would be nice if we can come up with a solution that
> doesn't lead to duplication of efforts from contributors to these two
> different projects like it is happening with GlusterFS now. How can we make
> that possible?
>

Okay. Now that I understand what you're looking for. Let me explain why
this project is split up.

We don't always test against HEAD. In the current state of the project
(glusto-tests), we'll be writing tests that apply to multiple versions of
Gluster simultaneously. That's why this project is split up. We often want
to test the latest tests against an older version. (For example, a point
release working fine). Glusto-tests are also end to end tests that are
expected to take more than 24 hours to do a complete run. So even for
Glusterfs, this is not something we're going to run per patch.

The goal that you have stated for gluster-block is slightly different from
our goals we have for glusto-tests with Gluster. There are some words of
caution:
* It's worth looking at how much time each test will add to your run. If
it's going to take more than 2h, you're probably better off without it.
* If this is what you want to do, remember, if you have to backport a fix
to an older release, you will not be able to run the latest tests against
them.
* The glusto-tests repo is where we coordinate testing. It's where we
manage the changes between versions of gluster and versioning. In short, if
you have problems, the place we collaborate to solve them is the
glusto-tests repo. If you choose to go the way of including tests in
gluster-block, you're going to be essentially a place where we can't sync
architecture changes with yours.
* This will create more work for automated testing overall as Rahul has
already said.

The way things are going, we want to be in a place where we can at any
point of time, we can tell the state of the entire stack -> Gluster + GD2 +
Gluster block. If you split this off, it's not going to make life
impossible for me or Vijay. It's going to create more work. The point I'm
not clear about is whether you have enough gain with this.

-- 
nigelb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/automated-testing/attachments/20180702/38206077/attachment.html>