-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/12/2015 11:45 AM, Loic Dachary wrote: > > > 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 ? When we first released on SLE12 yes, I haven't yet checked the latest master. Also if someone was "unusual" and used gentoo, mint, or other OS not in a database known OS, they might get "unusual" results. This is a use case example the use case is maybe beter stated: Handling of Operating systems which are not in the database of known operating systems. Best regards Owen >> >> 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJVUdWZAAoJECe/2BuiZiboAjwIAJGTYQZ20VLwExjFJHMeYtbO MfeIPTYOc5DislnkjLWT2eUjgejqBR6Hg5pBcl+/Xw6i7CrTnpSk82dO//JvWjwo bE2LHA/os0ssSivkzg2u1eslEYTEy1fspQzDiZv4k5L/6b+M9AAxkzxInYs8HUhi KcOw2BB92SToOQPSLdRtRcYdpCILTKWALy3LzbySIJdZXAv0BD4EYiNJax7CWH+A tfMmV1CTGduOCsAOmgTfFOcaL8DsDom4TSnp1Vqn2mNVEaChH4CmOpKsWW6ThXQ8 bjRhoTMZ20ZBbewfnfgulKMM1+tilnw4B4rA92F8ElfGgdrH49WvCLP8LjKD9EU= =insW -----END PGP SIGNATURE----- -- 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
