On 08/03/2015 09:07 PM, Sage Weil wrote: > On Mon, 3 Aug 2015, Owen Synge wrote: >> Dear all, >> >> My plan is to make a fedora22-systemd branch. I will leave fedora 20 as >> sysvinit. >> >> Ok just done my first proper install of systemd ceph branch on fedora22. >> >> I can confirm most of the issues. >> >> I am giving up for the day, but so far applying SUSE/opensuse code to >> Fedora ceph-deploy code in ceph-deploy has helped a lot. >> >> cp /usr/lib/python2.7/site-packages/ceph_deploy/hosts/suse/mon/* \ >> /usr/lib/python2.7/site-packages/ceph_deploy/hosts/fedora/mon/ >> >> (Running on suse version patched release) >> >> It can now set up the mon daemons correctly its self. >> >> I will look into the udev rules, tomorrow morning, and remove some more >> fedora hard coding to "sysvinit". I made a mistake, just doing the copy is enough to deploy mon and osd's I had made a typo to make me believe osd deployment was not. I will check the rgw. > There is a wip-systemd branch ceph-deploy that has enough ceph-deploy > changes for me to successfully do the deployment of mon, osd, mds, and > rgw. So can we merge the wip-systemd branch of ceph? This would then allow us to fix ceph-detect-init. This would also make it clearer to ceph-deploy developers what they need to do. > The main thing it doesn't do is figure out which version of Ceph > you're installing to decide whether to do systemd (post-hammer) or > sysvinit (hammer and earlier). That's going to be annoying, I'm afraid... I have not looked at the wip-systemd branch ceph-deploy, as I knew the SUSE version supported systemd, and knew their is no SUSE magic in the code as I wrote it, except supporting systemd. In principle, I agree it is a nice to have release version of ceph, changes in behaviour for ceph-deploy. I have great fears under the existing code style that adding an extra dimension will cause an explosion of branching code, in ceph-deploy which is in my opinion already far too large in terms of LOC/functionality. > I suspect what we really want to do is abstract out the systemd behavior > into something that the distros opt in to so that we aren't duplicating > code across the suse, centos, rhel, and fedora host types... Adding command line options to override "default" behaviour (or having a model as in MVC design pattern) might be a good way to start improving ceph-deploy to this objective. My opinion is better use of façade pattern to contain the explosion of conditionals and duplication that this would cause if the code is using current coding style, but moving toward MVC will also help. These 2 patches go a long way to solve the issues of duplicating code across the suse, centos, rhel, and fedora host types: https://github.com/ceph/ceph-deploy/pull/317 https://github.com/ceph/ceph-deploy/pull/318 Pull request #317 is how I should like to see the new code base evolve. Pull request #318 is within the current ceph-deploy code structure to see variables derived on a per distribution way. Combined these two patches show how I would move forward on ceph-deploy. This sort of façade pattern seems to avoid code duplication, already present all over the ceph-deploy code base. For now I suspect it is far easier to back port the option to use systemd to supported releases of hammer and earlier. To delay progress of ceph on ceph-deploy, is in my opinion the wrong thing to do, and I get the impression it is being maintained rather than pushing ceph or its self forward. Best regards Owen -- 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
