On 12/05/2015 12:27, Owen Synge wrote: > 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 ? That makes me curious about why it failed. There probably are similar problems with debian. Is there a tracker issue somewhere reporting this problem ? > 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 >>>>> >>>> >>> > > > -- Loïc Dachary, Artisan Logiciel Libre
Attachment:
signature.asc
Description: OpenPGP digital signature
