15:01:50 <bcoca> #startmeeting ansible core public irc meeting
15:01:50 <zodbot> Meeting started Thu Jan  9 15:01:50 2020 UTC.
15:01:50 <zodbot> This meeting is logged and archived in a public location.
15:01:50 <zodbot> The chair is bcoca. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:50 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:01:50 <zodbot> The meeting name has been set to 'ansible_core_public_irc_meeting'
15:02:07 <bcoca> jtyr  ?
15:03:14 <sdoran> o/
15:03:32 <maxamillion> .hello2
15:03:33 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
15:04:31 <bcoca> akasurde?
15:04:54 <bcoca> jakski?
15:13:48 <maxamillion> ....
15:13:52 <maxamillion> so quiet
15:13:59 <sdoran> 🦗
15:14:53 <cyberpear> o/
15:16:33 <cyberpear> I've got a couple of container- related e
15:16:50 <cyberpear> Fixes https://github.com/ansible/ansible/pull/66062
15:20:53 <bcoca> the systemd detection is wrong, it will create a lot more false positives
15:21:18 <bcoca> its already an issue and we removed the 'systemctl installed' detection for that reason, a lot of containers have it installed yet it is not the 'correct' one for managing services inside it
15:21:55 <cyberpear> What is a better way?
15:21:59 <bcoca> ^ container purists would argue that there is no service_mgr in containers since the contianer shoudl be 'the service' but many use them as light weight VMs which is why i still thnk  it shoudl be there
15:22:34 <bcoca> cyberpear: nto really, use= parameter in service action was put there cause there is no way to divine the 'intent' of the installation since it is too easy for containers to give contradictory information
15:22:49 <bcoca> specially since many of the container tech is meant to 'fake' system stuff like this
15:23:28 <bcoca> systemd is specially problematic since you might be using other services that depend on it being installed yet it is NOT what you are using for service management
15:23:29 <cyberpear> Do you know of a case where my change fails?
15:23:52 <bcoca> cyberpear: you can look at 'systemd container' search and a few dozen closed issues in github
15:24:00 <cyberpear> I tested Fedora, Debian, SUSE
15:24:21 <bcoca> everything from 'im really using an init script/supervise/daemontools' to 'containers should not have a service amnager'
15:24:34 <bcoca> cyberpear: its not about testing a distro, its about how people set thigns up
15:24:48 <bcoca> and when it comes to containers the real norm is 'there is no norm'
15:25:52 <cyberpear> Well,  sysvinit is wrong, which ends up getting chosen almost as a fallback
15:26:11 <bcoca> why we 'refined' detection to only work with 'clearly active' service mgr ... and it is still 'wrong' for many users since they avoid using THAT service manager for whatever reason (shell: nohup myscript.sh &)
15:26:29 <bcoca> cyberpear: its 'wrong for your case'
15:26:35 <bcoca> why i had to add 'use'
15:27:49 <bcoca> even on debian/ubuntu, services are not guareanteed to use systemd even if installed, specially when ppas are involved, systemd newer than jessie 'can' execute them but not enable/disable them ... so even with systemd installed and running its not always implemented in a way to handle 'the particluar services' a user is targetting
15:28:33 <bcoca> ^ official debian repo is supposed to have bot init and unit files as policy, but that does not translate to the myriad of external sources that can be used to install services
15:29:02 <cyberpear> sysvinit is detected solely by a path existing in /etc can we do the same for systemd?
15:29:42 <bcoca> no, since those are very diff requirements
15:29:52 <cyberpear> AFAICS, systemd is the only mgr we try to verify its actually running
15:30:23 <bcoca> cause many have systemd installed but dont use it as manager and it creates errors, if you have systemd and want to use init script, those still work
15:30:34 <bcoca> that is why the fallback works that way
15:31:34 <cyberpear> When would someone be using init scripts where /sbin/init doesn't exist?
15:32:22 <cyberpear> Or where it's a symlink to systemd?
15:32:26 <bcoca> several cases, not saying they are sane/good, but plenty of tickets show that happening 'in the wild'
15:32:53 <bcoca> aslo people using nohup on init script ..... which makes me want to yell at them but even ALL CAPS s not enough ...
15:32:59 <cyberpear> Was the detection previously checking those things?
15:33:03 <bcoca> yes
15:33:22 <bcoca> detection initially was basically 'which systemctl'
15:33:34 <bcoca> after many complaints we had to change to 'is systemd ACTUALLY RUNNING?!?!'
15:33:50 <cyberpear> But it didn't check /sbin/init?
15:34:16 <bcoca> we did, still didnt matter since docker would lie about that and say it was systemd, but still not have it runnig
15:34:23 <bcoca> so you could not use it to manage services
15:34:28 <bcoca> so service action woudl fail
15:34:43 <cyberpear> That's what my other PR fixes
15:35:42 <cyberpear> Obviously you can't start services without the mgr running, but you can enable/ disable/ mask
15:36:26 <bcoca> that pr will aslo not work
15:36:39 <bcoca> it breaks older systems
15:36:48 <cyberpear> Which ones?
15:37:02 <bcoca> systemd has changed interface over time .. and specially 'non good' implementatinos like jessie
15:37:22 <bcoca> so you cannot rely on 'enabled states'
15:37:58 <cyberpear> I tested back thru F18 GA, which is the older than jessie
15:38:11 <bcoca> at least you do account for chroot quircks, but those are not only ones at issue
15:38:52 <bcoca> cyberpear: age is one factor, implementation is another, jessie has a very 'quircky' implementation of systemd, a lot of things don't work as they were supposed to
15:39:30 <bcoca> fixed in newer debians (most of it) but that still leaves a quite large installed base of problems (hopefully will become mostly irrelevant in another 2yrs)
15:39:43 <cyberpear> Pretty sure I tested jessie, but I can again if it helps
15:40:07 <bcoca> i would aslo point to early arch/gentoo, but luckily those are rolling releases and really hard to find a production machine with the 'early quircks'
15:40:12 <cyberpear> Right, Jessie is now oldoldstable
15:41:24 <bcoca> and i would be more worried about RHEL6 than F18, but  .. upstart ...
15:41:44 <cyberpear> Right
15:42:50 <cyberpear> Same for RHEL 5, but you need ansible 2.3 against those, and it's sysvinit...
15:43:31 <bcoca> and yet we have people trying to run systemd and ansbile 2.9 on those ... luckily i get to ignore those, but cannot ignore (yet) a lot of the problematic systemd/container setups
15:44:07 <cyberpear> I'll test Jessie in several combos and and report back...
15:44:34 <bcoca> iirc jessie is at 215 .. and i already stated that it has a pretty 'non standard' implementation
15:44:44 <cyberpear> Any other problematic distros?
15:45:01 <bcoca> a few, but jessie is probably the most used/important and quirky
15:45:18 <bcoca> i would just have to search the dozens of ticktes for all the cases that made us change the detection
15:45:46 <cyberpear> Hopefully those tickets would have been referenced in the pr it made the change...
15:46:01 <bcoca> unsure, there have been a few dozen changes to detection
15:46:16 <bcoca> its not 'the one change' we tried to refine it several times till it became what it is today
15:46:38 <bcoca> and systemd status ... starts at the service.py module ... and moves across to the systemd.py one, so also a very long history
15:46:52 <bcoca> and you'll see many tickets stalled on changing how to manage that
15:47:42 <bcoca> on detection we basically went the most conservative possible and added use= to handle 'user configuration deviation' , i dont think we should change that at all
15:48:11 <bcoca> as for status managemnet, its mostly about 'installed base' since that is mostly connected to systemd version and implementation, so that change we might eventually merge
15:50:15 <bcoca> anything you wanted to discuss on 3rd ticket? container detection was merged
15:50:50 <cyberpear> Nothing specific. Thanks for approving it. M
15:51:26 <bcoca> np, that was a lot simpler to deal with ... and still the whole virtualization detection is wrong ... should be  'list' not single setting
15:51:58 <bcoca> ' i have docker container inside virtualbox inside kubernetes on openshipt on vmware on awx'
15:52:14 <cyberpear> Indeed
15:52:29 <bcoca> ^ i left out python venv .. casue not really related, but that was ACTUAL setup i had to help debug ansible issue with
15:52:41 <cyberpear> Best is to capture innermost if possible and only one
15:53:05 <cyberpear> The is-enabled does seem very straightforward to me, but I'll try to dig thru tickets to find what the issues were.
15:53:05 <bcoca> also, my workstation is host for  qemu, lxd, docker and virtualbox images ...
15:53:48 <cyberpear> Right, _host is even more problematic
15:54:23 <bcoca> k, if nothing else, ending meeting ... sadly very little 'resovled'
15:54:26 <bcoca> #endmeeting