19:00:16 <jillr> #startmeeting ansible core irc public meeting
19:00:16 <zodbot> Meeting started Tue Jan 21 19:00:16 2020 UTC.
19:00:16 <zodbot> This meeting is logged and archived in a public location.
19:00:16 <zodbot> The chair is jillr. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:16 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:00:16 <zodbot> The meeting name has been set to 'ansible_core_irc_public_meeting'
19:00:31 <jillr> #topic https://github.com/ansible/ansible/pull/65745
19:00:37 <jillr> felixfontein: you're up!
19:01:16 <jillr> it's been a bit so we have quite a list, we'll do the best we can do whittle it down
19:01:30 <felixfontein> ah, I thought first would be the missing items from last year
19:01:30 * dmellado misses gerrit topics just so much xD
19:01:44 <jillr> oh did I miss some in the issue, oops...
19:01:47 * jillr rechecks
19:02:14 <jillr> ah I did
19:02:26 <felixfontein> I mainly put up the sanity check PRs (and tremble did too) to get feedback and hopefully approval for them; IMO these should be merged soon so that people know about sanity problems before modules are moved to collections
19:03:00 <jillr> lets go ahead and look at this one then I'll backtrack to the carry over for the next topic
19:03:09 <felixfontein> ok
19:03:28 <cyberpear> We're not planning to break 2.9 for folks who haven't migrated off the deprecated stuff, are we?
19:03:37 <felixfontein> this one improves the deprecation sanity check, and removes something which should have been removed for ansible 2.9
19:04:00 <tremble> I guess the question is do you plan to backport the removals?
19:04:00 <felixfontein> I wouldn't backport it, but it would be nice if the stuff would be gone in 2.10 ;)
19:04:05 <dmellado> cyberpear: that's what deprecation messages are for ;)
19:04:11 <felixfontein> I don't plan to
19:04:30 <dmellado> I would add the deprecation messages and address some date in the future, but *not* do any breakages as of now
19:05:08 <jillr> the deprecation messages were already there though, for 2.9 removal, right?  (still reading)
19:05:17 <felixfontein> yep
19:05:36 <felixfontein> the problem was that the sanity check for finding deprecation messages wasn't sufficient to find it, and thus it was overlooked
19:06:33 <felixfontein> the fix for the sanity check was suggested by sivel in https://github.com/ansible/ansible/issues/65471#issuecomment-561354567
19:07:06 <dmellado> felixfontein: I see
19:07:26 <dmellado> felixfontein: did you happen to find any another violation after the fix?
19:07:58 <felixfontein> yes, I created issue(s) for that
19:08:06 <dmellado> awesome, thank you for that!
19:08:14 <felixfontein> others were in modules
19:08:35 <dmellado> in any case I do hope that at some point, zuul will be in place and find out all that stuff directly
19:09:13 <felixfontein> there's another PR (incomplete) for some stuff which should be removed from Azure modules (https://github.com/ansible/ansible/pull/65749), it's incomplete since it requires massive changes to the tests and I don't want to do that
19:10:00 <jillr> this change seems sane to me
19:11:22 <jillr> anyone disagree?
19:13:45 <jillr> dmellado: what do you think?
19:14:33 <dmellado> jillr seems sane to me
19:14:39 <dmellado> let me check if there's any fragment
19:15:39 <dmellado> yeah, there is, +1 from my side, although I have to admit that I'm totally newbie to Azure
19:15:40 <felixfontein> if you mean changelog fragment, yes there is :)
19:16:20 <felixfontein> dmellado: the only azure part it touches is a AnsibleModule wrapper which has support for that option which is removed
19:16:51 <felixfontein> since none of the bundled Azure modules use that, it should be pretty safe to simply remove it as well
19:16:59 <felixfontein> (use that option, I mean)
19:17:48 <dmellado> felixfontein: thanks for the explanation
19:17:52 <dmellado> +1 from my side ;)
19:18:37 <felixfontein> thanks jillr and dmellado!
19:18:42 <jillr> awesome
19:18:49 <jillr> #topic https://github.com/ansible/ansible/pull/62662
19:18:51 <felixfontein> (is nobody else around today?)
19:19:08 <jillr> hm I dont think jtyr is online
19:19:11 <felixfontein> I'll do a rebuild_merge then
19:19:12 <dmellado> heh, not sure tbh, I'm doing 'odd' hours today tbh
19:19:14 <dmellado> ;)
19:19:15 * cyberpear waves
19:19:35 <jillr> hey cyberpear o/
19:19:48 <felixfontein> ah, sorry I forgot you cyberpear, you already wrote something above :)
19:19:58 <cyberpear> (but not my PR under discussion, though :P )
19:20:39 <jillr> this one was also extensively discussed previously so we'd probably need more cores present anyway
19:20:40 <felixfontein> cyberpear: since both jtyr and akasurde aren't here, your PRs will probably come up next
19:20:48 * Jakski_ waves
19:20:49 <felixfontein> ah, already is
19:20:53 <felixfontein> I got confused with the PR #...
19:21:34 <jillr> #topic https://github.com/ansible/ansible/pull/66062
19:22:32 <cyberpear> I hope this one is straightforward, and it is probably easiest to review by looking at each commit
19:22:33 <felixfontein> 62662 and 66062 are easy to confuse
19:22:40 <cyberpear> yeah
19:25:33 <cyberpear> basically, the PR adjusts the module to use `systemctl is-enabled` as a fallback to check whether a service is a valid systemd service.  This removes the requirement for systemd to actually be running, allowing the module to be used during container build
19:26:11 <bcoca> still breaks for systems that have it linked but are not using it as the service manager
19:26:41 <cyberpear> bcoca: in that case, the user wouldn't be using the `systemd` module
19:27:21 <cyberpear> bcoca: and in that case, the user might have a useless symlink
19:27:22 <dmellado> I have to drop for today folks, cya! o/
19:27:34 <felixfontein> bye dmellado!
19:27:34 <bcoca> depends,  service module ... but at that point i would makethem use=sysvinit or other
19:27:36 <jillr> thanks dmellado, have a good night!
19:27:40 <agaffney> cyberpear: never underestimate the ability for the user to do very silly things
19:28:00 <bcoca> cyberpear: not useless .. but mostly, it is there to fool detection for systems that 'require but dont use systemd'
19:28:18 <bcoca> ... which is stupid itself .. but this is just a chain of stupidity imho ...
19:28:52 <cyberpear> agaffney: why should knowledgeable users be prevented from doing work for the sake of those who know what they're doing?
19:28:54 <bcoca> im fine with this change as is
19:29:30 <bcoca> diff isuse would be to update facts/service detection, but once on systemd module , i'm fine with failing and forcing user to actually 'tell us' which srvc mgr they actually want
19:29:54 <bcoca> cyberpear: not stoping, just noting
19:29:57 <bcoca> noteing ?
19:30:01 <bcoca> make a note
19:30:18 <cyberpear> agaffney: would you be happier if I add a warning if this code path is met?  We already reach a similar path with chroot case, where systemd is running, but not managing the chroot (such as kickstart post scripts)
19:30:18 <felixfontein> noting
19:30:33 <bcoca> for this one iwas more worried about valid enabled states, but you tested the older systemd versions
19:30:45 <cyberpear> I tested all the way back to the version stated
19:31:11 <cyberpear> which is older than any vendor-supported LTS distro with systemd
19:31:22 <bcoca> which sadly is not all the ones out ther .. but im fine with 242 (the problem child) to require older versions of the module
19:31:28 <bcoca> 224?
19:31:30 <bcoca> i forget
19:31:54 <cyberpear> works all the way back to 195
19:32:14 <agaffney> cyberpear: you seem to be assuming that I was arguing against what you're trying to do. I simple commented that users do silly things
19:32:17 <felixfontein> 244 seems to be latest
19:32:22 <bcoca> u sure? there were major chanes in status and return codes in early 200s
19:32:23 <cyberpear> agaffney: fair enough
19:32:32 <jillr> this lgtm as well
19:32:44 <cyberpear> I tested my change to the module w/ systemd 195 as shipped in Fedora 18 GA release
19:33:06 <bcoca> i looked at my older images and it worked fine also
19:33:15 <cyberpear> (which I think is where RHEL 7 was branched)
19:33:29 <cyberpear> (current RHEL 7 has systemd-219)
19:33:32 <bcoca> 152 was 'problem child' ... found the note
19:33:37 <cyberpear> aha!
19:33:48 <cyberpear> I hope no one is running that, but I guess...
19:34:09 <cyberpear> at what point to we say to long-EOL distros "sorry, we can't support you"
19:34:12 <bcoca> they are ..b ut as i said above, im fine with them being restricted to older ansible
19:34:34 <cyberpear> I mean RHEL 5 is still supported by RH until end of Nov, but we dropped support for that in ansible 2.4
19:34:35 <bcoca> cyberpear: at the point tht more pitchforks appear for us to move on vs those that appear for us to stay
19:35:02 <bcoca> .. and we've had pitchforks cause of that .. but not enough to worry us
19:35:23 <jillr> it sounds like we have agreement on this one?
19:35:28 <cyberpear> (I generally keep ansible 2.3 compat w/in roles for the reason of being able to run on the old RHEL 5)
19:35:28 <bcoca> yep
19:35:36 <jillr> cool, shipit
19:35:43 <cyberpear> thanks!
19:35:49 <jillr> #topic https://github.com/ansible/ansible/pull/66071
19:36:03 <jillr> still on the topic of systemd :)
19:36:05 <cyberpear> so this is the one bcoca is concerned about
19:36:18 <bcoca> this one breaks on my workstation ...
19:36:29 <cyberpear> I've modified this so that it only detects systemd if `systemctl` command is available and `/sbin/init` is a symlink to `systemd`
19:36:39 * jillr puts bcoca's workstation into CI  ;)
19:36:44 <cyberpear> bcoca: have you tested since I made that change?
19:36:57 <cyberpear> I made that after you originally tested it
19:37:01 <bcoca> jillr:  no one wants to run gentoo/openrc wth docker/f28 with systemd
19:37:04 <bcoca> cyberpear: yes
19:37:24 <cyberpear> bcoca: what made the `/sbin/init` link to `systemd`?
19:37:52 <bcoca> the issue is that some combinatiosn of 'non systemd' hsots with 'systemd container os' 'fake link' the init so 'things work' in the container but dont actually use systemd
19:38:00 <bcoca> cyberpear: afaik, docker
19:38:10 <cyberpear> bcoca: I'm not familiar enough w/ openrc... wouldn't openrc make its own symlink from /sbin/init?
19:38:15 <bcoca> though i switch back n forth with lxd
19:38:27 <bcoca> cyberpear: on host system, yes, but not for containers
19:38:31 <cyberpear> can you do the equivalent of `rpm -qf /sbin/init` to find which package it came from?
19:38:36 <bcoca> systemd
19:39:10 <bcoca> the 'contained'  looks like it normally would
19:39:29 <bcoca> its just niot realy executing /sbin/init
19:39:52 <bcoca> i 'could' execute it, but that is not what is used to manage the service
19:40:24 <cyberpear> bcoca: the openrc test comes before the systemd-offline test... does that not catch your cases?
19:40:43 <cyberpear> bcoca: do you expect it to return sysvinit on your openrc system?
19:41:21 <cyberpear> bcoca: does your system run sysvinit?  I think sysvinit /always/ uses `/sbin/init`, doesn't it?
19:41:27 <bcoca> no, not using either for services on that docker image
19:42:16 <bcoca> not testing the 'host service manage'r, but the 'conatiner service manager', which many times has 'init is a lie'
19:42:23 <cyberpear> so it's not incorrect to say that if systemd is a service manager installed, that that's a reasonably-appropriate `service_mgr` in my mind... it's just as meaningless as `sysvinit` if you aren't actually using a `service_mgr` at all
19:43:00 <bcoca> cyberpear: i also have both upstart and systemd installed on same container
19:43:03 <cyberpear> especially if systemd is installed in the container but sysvinit is not
19:43:29 <bcoca> sysvinit is the fallback cause openrc/upstart/systemd/etc all fall back to init scripts
19:43:33 <cyberpear> bcoca: does upstart run w/in a container?
19:43:41 <bcoca> yes, not easy, but also does systemd
19:44:01 <bcoca> there are good instructions on doing both ... just not for feint of heart
19:44:09 <cyberpear> Red Hat added dumb-init to the rhel6-init container rather that the RHEL6-native upstart
19:44:50 <bcoca> which i've also found to give false positives, mostly we fallback to sysvinit in those cases
19:44:54 <cyberpear> bcoca: can you point a dockerhub link to a container w/ both upstart and systemd so I can test?
19:45:14 <bcoca> not that i know of, i had to build all from scratch
19:45:43 <cyberpear> do you know of any real-world examples where my PR might break something?
19:46:19 <bcoca> for start, mine, which was created due to user complaints, i mostly mirrored what they had
19:46:26 <bcoca> containers running x service
19:47:09 <cyberpear> could you provide an issue link? -- I searched for issues on the topic but didn't find anything supecificalyl related... this code has been virtually unchanged since it was introduced to ansible
19:47:38 <bcoca> most of the code came from service module, it has changed a lot, just not in current location
19:47:40 <cyberpear> I mean, I could install an opensuse container w/ systemd and make /sbin/init as symlink to /bin/bash, but that would be contrived, and w/ this PR, it would default to `sysvinit`
19:47:52 <bcoca> also facts revamp moved this code from original positin
19:48:02 <cyberpear> yeah, I followed it back past the facts revamp
19:48:03 <felixfontein> does it make sense to continue this discussion here?
19:49:03 <cyberpear> does anyone else have any opinion? -- it seems pretty reasonable to me that if /sbin/init is a symlink to systemd, that the system `service_mgr` is reasonably expected to be systemd.
19:49:09 <bcoca> cyberpear: it mostly was not 'standard setups' but people that went through the trouble of runnign systemd and upstart under docker .. which i challenge their sanity .. it took me along time to setup same and there are no good instructions out there (xcept for fedora)
19:49:10 <cyberpear> or an alternate approach?
19:49:56 <bcoca> https://developers.redhat.com/blog/2016/09/13/running-systemd-in-a-non-privileged-container/
19:49:56 <felixfontein> cyberpear: sorry no... I'm not using init systems in containers or strange setups :)
19:50:25 <bcoca> ^ well, that is the other side of coin, most 'container theory' go against service managers, since 'the container is the service'TM
19:50:49 <bcoca> so container mangment software is designed to 'lie' in the first place
19:51:03 <cyberpear> indeed, but it's super useful for testing w/o needing overhead of a full VM
19:51:07 <bcoca> cyberpear: i have not found a way that passes the corner cases i have
19:51:26 <bcoca> cyberpear: which is one reason i use them as 'light weight vms' .. which goes against 'container theory'
19:51:42 <jillr> tbh it sounds like this one is a lot of edge cases, and I dont feel familiar enough with them to really weigh in
19:51:46 <bcoca> its a lot faster than spinning up full vms just to test systemd and upstart
19:51:53 <cyberpear> I'd argue that running ansible to build a container as described in the linked article (using such as ansible-bender) is less of an edge case...
19:52:08 <bcoca> jillr: sadly 'service managers' + 'containers' is ALL edge cases
19:52:16 <cyberpear> takes me 3 seconds to spin up a systemd container
19:52:19 <jillr> yarly
19:52:35 <cyberpear> okay, let's table until next time when maybe more folks will weigh in?
19:52:50 <jillr> sorry cyberpear, thanks for putting the worl into it!
19:52:50 <cyberpear> (so we can get to felixfontein PRs)
19:52:52 <jillr> *work
19:52:57 <bcoca> cyberpear:  once you find out how to do it, lot easier to autmoate, but not that easy to find instructions on running upstart inside container
19:52:59 <felixfontein> (and maybe even tremble's)
19:53:13 <jillr> #topic https://github.com/ansible/ansible/pull/65747
19:53:27 <cyberpear> `podman run -d ubi7-init` `podman exec -it -l`
19:53:40 <felixfontein> that PR is a revival of a PR by sivel, it does stricter argument_spec checking
19:53:43 <bcoca> ^ i have playbook with the RH link above, but didnt do it for upstart
19:53:43 <cyberpear> ^ literally that simple; RH did all the work to set it up for us
19:53:45 <felixfontein> (with schema validation)
19:54:12 <felixfontein> (ignore.txt is out of date, I'll fix that before merging otherwise it's just outdated again when it's time for merging...)
19:54:14 * bcoca has not touched podman yet
19:54:30 <bcoca> felixfontein: i have 2 abandoned PRs just cause of ignore.txt
19:54:39 <felixfontein> podman allows to install a docker CLI replacement which breaks (or at least broke) the docker connection plugin
19:55:00 <bcoca> wee
19:55:06 <cyberpear> (wouldn't surprise me)
19:55:23 <felixfontein> bcoca: one of them https://github.com/ansible/ansible/pull/58646 ? I can update it, but it would be nice if someone else could OK it so merging will be fine
19:56:09 <bcoca> i have been waiting for 'someone else' months ...
19:56:21 <felixfontein> anyway, I think it's really important to get most ansible-test changes merged ASAP so that there will be less trouble when modules are moved to other repositories
19:56:53 <felixfontein> dag: any comment on the current form of https://github.com/ansible/ansible/pull/58646 ?
19:59:05 <felixfontein> anyone wants to comment on sanity tests?
20:00:06 <jillr> sorry felixfontein, still reading through your pr. I'm not as familiar with the schema validation code so it's taking some digesting.
20:00:41 <jillr> ah and we're at the top of the hour
20:02:10 <jillr> I'm going to say +0 just for needing more time to dig into it
20:02:28 <felixfontein> ok
20:02:43 <jillr> I'm not aware of any reason we wouldnt have the usual Thur meeting this week though so hopefully folks can dig into it before then
20:02:55 <jillr> thanks everyone!
20:02:59 <jillr> #endmeeting