It also doesn't seem like it would actually present a problem in any case. -Sam On Wed, Apr 13, 2016 at 11:31 AM, John Spray <jspray@xxxxxxxxxx> wrote: > On Wed, Apr 13, 2016 at 2:58 PM, Gregory Farnum <gfarnum@xxxxxxxxxx> wrote: >> On Wed, Apr 13, 2016 at 6:23 AM, Loic Dachary <loic@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
