Re: [Ceph-qa] ceph-qa-suite branching (merge it into ceph.git?)

[Samuel Just <sjust@redhat.com>]

Ah, I didn't know about that, I'll have to try it.
-Sam

On Wed, Apr 13, 2016 at 2:09 PM, Loic Dachary <loic@dachary.org> wrote:
>
>
> On 13/04/2016 22:12, Josh Durgin wrote:
>> On 04/13/2016 11:38 AM, Sage Weil wrote:
>>> On Wed, 13 Apr 2016, Samuel Just wrote:
>>>> It also doesn't seem like it would actually present a problem in any case.
>>>
>>> The reason we didn't do this before was because we wanted to revise tests
>>> independently of the thing being tested.  But as John points out,
>>> specifying a test branch should accomplish that, at least for testing.
>>>
>>> It might be nice to preserve the ability specify an alternate repo with
>>> totally out-of-tree tests.  Maybe that can be done with a simple reorg of
>>> the repo, like putting everything under qa/, so that tasks/ and suites/
>>> don't appear at the top level (of ceph.git or ceph-qa-suite.git).
>>
>> It'll also be quite helpful to specify an alternate repo (not just
>> branch) for testing suite changes without pushing to the main ceph.git
>> and triggering gitbuilder builds.
>
> We can keep the current --ceph-qa-suite-git-url argument for that. Or do you have something else in mind ?
>
>> Josh
>>
>>> sage
>>>
>>>
>>>
>>>> -Sam
>>>>
>>>> On Wed, Apr 13, 2016 at 11:31 AM, John Spray <jspray@redhat.com> wrote:
>>>>> On Wed, Apr 13, 2016 at 2:58 PM, Gregory Farnum <gfarnum@redhat.com> wrote:
>>>>>> On Wed, Apr 13, 2016 at 6:23 AM, Loic Dachary <loic@dachary.org> wrote:
>>>>>>> +1 : I agree it would be a good thing.
>>>>>>>
>>>>>>> The reason why it would help to merge ceph-qa-suite in ceph is because we have no proper methods or tools to work with interdependent repositories. The problem is not unique to Ceph: every Free Software developer end up bug fixing and adding features to dependencies (ceph-qa-suite in the case of Ceph but also jerasure, rocksdb, s3test etc.). It will take a long time to resolve that more general problem and I don't know about an effort in that direction. Do you ?
>>>>>>>
>>>>>>> Cheers
>>>>>>>
>>>>>>> On 13/04/2016 12:52, John Spray wrote:
>>>>>>>> Lately, we've instances where ceph.git and ceph-qa-suite.git got
>>>>>>>> slightly out of sync, as we were adding new stuff and interface
>>>>>>>> changes to ceph (especially in cephfs).
>>>>>>>>
>>>>>>>> We used to have two repos (ceph and teuthology), now we have three
>>>>>>>> (ceph, ceph-qa-suite and teuthology).  Splitting tests out of
>>>>>>>> teuthology was a good thing, but maybe they should have gone into the
>>>>>>>> ceph tree instead of a new repo?  The ceph-qa-suite branching seems to
>>>>>>>> pretty much mirror what we do with ceph, with master vs jewel etc.
>>>>>>>>
>>>>>>>> Historically we had a comparatively static set of workloads in the qa
>>>>>>>> suite (e.g. kernel-untar-build, fsstresss, pjd), which didn't change
>>>>>>>> much with ceph changes.  But these days we're adding much more
>>>>>>>> detailed tests, so there's more effort to keep the two in sync.
>>>>>>>>
>>>>>>>> I would personally love to be able to have a single PR that contained
>>>>>>>> my code and the tests for it.  What if after Jewel we pulled all of
>>>>>>>> ceph-qa-suite into the ceph repo?
>>>>>>>>
>>>>>>>> We could still enable folks running test changes without having to
>>>>>>>> rebuild ceph packages: the suite sha1 selected when running a
>>>>>>>> teuthology suite could still be different from that used for
>>>>>>>> installing ceph, it's just that it would fetch that sha1 from the ceph
>>>>>>>> repo instead of from a separate repo.
>>>>>>
>>>>>> We do have qa-suite tests that don't necessarily make a lot of sense
>>>>>> to have in ceph.git. Samba, kernel NFS, ganesha some day. That doesn't
>>>>>> mean we shouldn't merge them, but it popped into my head.
>>>>>
>>>>> Fair point.  I think that because those other tasks depend in turn on
>>>>> the ceph tasks, we still ultimately benefit from having them in one
>>>>> place.
>>>>>
>>>>> It's also possible that in the long run things like the samba tests
>>>>> become a bit more "smart" in a way that's more tightly coupled to
>>>>> ceph, e.g. checking the resulting state inside ceph after doing things
>>>>> in the samba/ganesha layer, at which point we'd enjoy having them in
>>>>> the same place as the main body of test code.
>>>>>
>>>>> John
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>>>>> the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>> _______________________________________________
>>>> Ceph-qa mailing list
>>>> Ceph-qa@lists.ceph.com
>>>> http://lists.ceph.com/listinfo.cgi/ceph-qa-ceph.com
>>>>
>>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>
>>
>
> --
> Loïc Dachary, Artisan Logiciel Libre
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html