On 05/11/2015 11:45 PM, Loic Dachary wrote: > Hi Owen, > > It would help to provide one or two use cases where (C) solves a problem > that (B) (that is the current ceph-detect-init approach) does not > solve. > I sense there is something better in (C) but I can't think of a use case > just now > (maybe because I've been thinking about erasure code all day :-). Hi Loic, Please note that I believe we are correct to explicitly allow the user to specify the init system and override any auto detection. Hence I believe it is correct for autodetection to be able to fail. Use case (1) ~~~~~~~~~~~~ When a new release of an operating system comes out with a different init system (B) as a static database will not immediately account for this solution. For example SUSE SLE 11 -> sysV SUSE SLE 12 -> systemd RHEL 5 -> sysV RHEL 6 -> upstart RHEL 7 -> systemd When for example SLE12 came out ceph upstream code assumed ceph ran on the sysV init system until appropriate patches where taken. Since we can only test on "free as in beer" operating systems at this moment covering these OS's with the database and appropriate tests is problematic. Use case (2) ~~~~~~~~~~~~ The use cases are on the latest debian, ubuntu platforms. On both these platforms you can install alternative init systems. on debian stable I can apt-get install the following init systems: systemd upstart sysvinit Hence assuming all debian stable systems are systemd (the default) is a false assumption as (B) does not support users changing the init system before installing ceph on debian and ubuntu as having a database of init systems cannot support all platforms. Use case (3) ~~~~~~~~~~~~ By supporting (B) and (C) and emitting a warning on operating systems not in the database, populating the database will be quicker, and correcting values in the database will be easier to verify. In some ways, the code tests its self, at run time. Summary: ~~~~~~~~ I think its a value decision, is the extra complexity of doing (B) and (C) worth the corner case of supporting the people who chose to use non default init system worth the code complexity. If we are supporting more than one init detection mechanism, it may well be worth supporting all of (A) (B) and (c). Best regards Owen > Cheers > > On 11/05/2015 18:29, Owen Synge wrote: >> Dear all, >> >> Many init systems are used in linux now. Some ceph code needs to know >> the init system. (I must admit I have not looked into Solaris, MacOS and >> BSD and probably should have) >> >> It would be nice to have one function that detects the init system >> >> Since the init system can be specified in ceph and ceph-deploy >> explicitly it seems to be its reasonable to fail clearly to detect init >> system. >> >> I see 4 ways I can see to detect init system. >> >> (A) Check pid 1. >> (B) Use a database of OS to init mapping / compile time. >> (C) look for init manipulation tools and infure the init system from tools. >> >> Comments: >> ~~~~~~~~ >> >> (A1) systmd can be detected easily with. >> >> grep -qs systemd /proc/1/comm >> >> (A2) With init scripts such as its hard to know what the init system. >> >> (B1) For operating systems like RHEL, SLE, CENTOS, Fedora and scientific >> linux this works well. >> >> (B2) FOr operating systems like newer debian and ubuntu releases more >> than one init system can be installed and used on the OS, so making a >> database / doing it at compile time are not practical on all OS's >> >> (C1) This is fairly reliable. >> >> (C2) sysV tools have compatibility scripts / programs on other platforms >> so if you use a points system for each init system helper script you can >> infure systemd over sysV if sytemctrl exists for example. >> >> So to summarise this: >> ~~~~~~~~~~~~~~~~~~~~ >> >> (1) No one system is perfect in all cases. >> (2) Combined these systesm can provide reliable init system detection. >> >> My proposed approach. >> ~~~~~~~~~~~~~~~~~~~~ >> >> (I) Use all three approaches where each approach can provide and answer, >> or fail to provide an answer. >> >> (II) Should any approaches disagree -> fail to detect init system. >> >> (III) Should all approaches agree -> then return init system. >> >> (III) Should no approaches provide an init system -> fail to return init >> system. >> >> Comments >> ~~~~~~~~ >> >> This multi layered and comparing way of doing init systems may seem >> complete overkill, or maybe its useful. >> >> What do you guys think? >> >> 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 >> > -- SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- 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
