On 12/05/2015 09:56, Owen Synge wrote: > 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. So Ceph failed to run on SLE12 because it was relying on sysV ? > > 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 >>> >> > -- Loïc Dachary, Artisan Logiciel Libre
Attachment:
signature.asc
Description: OpenPGP digital signature
