+1 for "atomic" PR, this should solve the problem. On Wed, Apr 13, 2016 at 11:23 AM, Samuel Just <sjust@xxxxxxxxxx> wrote: > This seems tidy to me. I'd love to be able to merge a PR with it's > ceph-qa-suite PR "atomically". > -Sam > > On Wed, Apr 13, 2016 at 11:10 AM, Vasu Kulkarni <vakulkar@xxxxxxxxxx> wrote: >> Sorry for spam, the first one was rejected due to text/html format. >> >> On Wed, Apr 13, 2016 at 3:52 AM, John Spray <jspray@xxxxxxxxxx> 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). >> >> >> we also have s3 suites in its own repo, we have big files in >> ceph.com/qa which i believe is the right place. >> >>> >>> 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? >> >> >> I understand the advantage of having same sha between builds and >> tests, but how are we going to guarantee ceph-builds in different >> places(one built on other than ceph.com) will have same sha? >> why not move ceph tests from ceph.git into ceph-qa-suite, Ideally >> this is not an issue with any major release, jewel workunits are >> supposed to work with jewel ceph, >> only in rare cases it may cause some issue but easily fixable. All the >> dev runs can point to any qa-sha using the cli option so much less of >> an issue in rare case. >> >>> >>> 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. >>> >>> 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 -- 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
