>> >> I think having one part of Ceph on a different release cycle to the >> rest of Ceph is an even more dramatic thing than having it in a >> separate git repository. >> >> It seems like there is some dissatisfaction with how the Ceph project >> as whole is doing things that is driving you to try and do work >> outside of the repo where the rest of the project lives -- if the >> release cycles or test infrastructure within Ceph are not adequate for >> the tool that formats drives for OSDs, what can we do to fix them? > > It isn't Ceph the project :) I think there needs to be a distinction between things that *are* ceph (CephFS, RBD, RGW, MON, OSD) and things that might leverage ceph or help with it's installation / usage (ceph-ansible, ceph-deploy, ceph-installer, ceph-volume). I don't think the later group needs to be in ceph.git. >> >> I guess my argument isn't so much an argument as it is an assertion >> that if you want to go your own way then you need to have a really >> strong clear reason. > > Many! Like I mentioned: easier testing, faster release cycle, can > publish in any package index, doesn't need anything in ceph.git to > operate, etc.. I agree with all these points. I would add that having ceph-volume in a separate git repo greatly simplifies the CI interaction with the project. When I submit a PR to ceph-volume.git I'd want all our unit tests run and any new docs automatically published. If this lived in ceph.git it's very clumsy (maybe not possible) to have a jenkins react and start jobs that only pertain to the code being changed. If I submit new ceph-volume code why would I need make check ran or ceph packages built? Having ceph-disk tied to ceph.git (and it's release cycle) has caused problems with ceph-docker in the past. We've had a race condition (in ceph-disk) that exposes itself in our CI present for quite some time even though the patch was merged to master upstream. I think the fixed missed the 2.3 downstream release as well because it wasn't back ported quickly enough. Keeping tools like ceph-disk or ceph-volume outside of ceph.git would allow us to merge those fixes back into ceph-docker more efficiently. Maybe I don't understand the strong reasons for keeping ceph-volume in ceph.git? If it's only for parity in branches, I never thought of ceph-volume having a branch per version of ceph supported anyway. I'd expect it to have numbered releases that support a documented number of ceph releases, ceph-ansible works similarly here and I believe ceph-deploy did as well. - Andrew _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |