16:22:55 <skunkerk> #startmeeting fedora_coreos_meeting
16:22:55 <zodbot> Meeting started Wed Mar  4 16:22:55 2020 UTC.
16:22:55 <zodbot> This meeting is logged and archived in a public location.
16:22:55 <zodbot> The chair is skunkerk. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:22:55 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:22:55 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:28:25 <c_insighter> hello
16:28:33 <red_beard> aloha
16:28:45 <red_beard> .hello redbeard
16:28:46 <zodbot> red_beard: redbeard 'Brian 'redbeard' Harrington' <bharring@redhat.com>
16:30:04 <zodbot> jlebon: Error: Can't start another meeting, one is in progress.
16:30:29 <red_beard> jlebon: skunkerk is the current chair
16:30:35 <cyberpear> o/
16:30:41 <cyberpear> .hello2
16:30:42 <zodbot> cyberpear: cyberpear 'James Cassell' <fedoraproject@cyberpear.com>
16:31:06 <c_insighter> .hello creativeinsighter
16:31:07 <zodbot> c_insighter: creativeinsighter 'Creative Insights' <creative.insights@protonmail.com>
16:31:43 <dustyweb83> hey all - I'm working on recovering my IRC server. In the mean time I'm dustyweb83
16:31:56 <jlebon> skunkerk: hmm don't think we've met before :)
16:32:28 <lorbus> .hello2
16:32:29 <jlebon> did you want to lead this meeting?
16:32:29 <zodbot> lorbus: lorbus 'Christian Glombek' <cglombek@redhat.com>
16:32:37 <jlebon> .hello2
16:32:38 <zodbot> jlebon: jlebon 'None' <jonathan@jlebon.com>
16:32:54 <dustyweb83> jlebon - was that a question for me?
16:32:58 <jlebon> #chair lorbus dustyweb83
16:33:14 <jlebon> dustyweb83: current meeting chair is a certain skunkerk
16:33:20 <skunkerk> jlebon, Sorry that was a mistake. This is my first meeting.
16:33:45 <skunkerk> didn't intend to chair the meeting though :)
16:33:48 <jlebon> skunkerk: ahhh np. if you #chair me, i can take over :)
16:33:53 <red_beard> skunkerk: copy/pasta that last line jlebon  threw in to make them chairs
16:34:34 <skunkerk> #chair jlebon
16:34:34 <zodbot> Current chairs: jlebon skunkerk
16:34:40 <jlebon> #topic roll call
16:34:47 <jlebon> #chair lorbus red_beard dustyweb83
16:34:47 <zodbot> Current chairs: dustyweb83 jlebon lorbus red_beard skunkerk
16:35:02 <jlebon> #chair cyberpear
16:35:02 <zodbot> Current chairs: cyberpear dustyweb83 jlebon lorbus red_beard skunkerk
16:35:31 <jlebon> will give it one more minute for late comers
16:35:52 <dustymabe> .hello2
16:35:53 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:35:57 <jlebon> #chair dustymabe
16:35:57 <zodbot> Current chairs: cyberpear dustymabe dustyweb83 jlebon lorbus red_beard skunkerk
16:36:00 <dustymabe> yay.. i'm here with my real nick
16:36:03 <c_insighter> don't mind me, I'm still new here
16:36:12 <jlebon> #topic Action items from last meeting
16:36:20 * jlebon dustymabe to create issue to discuss possibilities for a "reliable extensions" framework
16:36:36 <jlebon> pretty sure this happened :)
16:36:45 <dustymabe> one sec
16:37:17 <dustymabe> #info dustymabe created #401 to discuss the feature request for a reliable extensions framework: https://github.com/coreos/fedora-coreos-tracker/issues/401
16:38:10 <jlebon> lots of good discussions happening there already
16:38:35 <jlebon> when you have time, have a look if you haven't already
16:38:47 <jlebon> dustymabe: anything you wanted to add about this?
16:40:07 <dustymabe> nope
16:40:19 <jlebon> #topic enable `container_manage_cgroup` SELinux boolean by default
16:40:25 <miabbott> .hello2
16:40:26 <zodbot> miabbott: miabbott 'Micah Abbott' <miabbott@redhat.com>
16:40:28 <jlebon> #link https://github.com/coreos/fedora-coreos-tracker/issues/397
16:40:33 <jlebon> #chair miabbott
16:40:33 <zodbot> Current chairs: cyberpear dustymabe dustyweb83 jlebon lorbus miabbott red_beard skunkerk
16:40:50 <cyberpear> -1 to the suggestion
16:40:59 <cyberpear> but I just opened https://github.com/coreos/fedora-coreos-config/pull/291
16:41:00 <ksinny> .hello sinnykumari
16:41:01 <zodbot> ksinny: sinnykumari 'Sinny Kumari' <ksinny@gmail.com>
16:41:04 <cyberpear> as a workaround
16:41:27 <jlebon> so the TL;DR on this is: you need a certain seboolean flipped to have systemd run in containers, but then it enables cgroup management for all containers which have access to it
16:42:18 <cyberpear> finally got some clarification on the security ramifications of such a change in https://bugzilla.redhat.com/show_bug.cgi?id=1806038#c8
16:42:59 <jlebon> cyberpear: thanks. though the seboolean itself is too coarse
16:43:09 <red_beard> the comments in the issue look like half "i needed to do this" and half "it might break things"
16:43:19 <cyberpear> right -- quoting from the RHBZ "it opens a fairly large security whole in that turning it on from an SELinux point of view allows all containers to modify cgroups if they get ahold of a cgroup file system."
16:43:44 <cyberpear> but until cgroupfs supports selinux labels, it's the only way to run systemd in the container
16:43:45 <dustymabe> correct. I was originally +1, but after reading that I reconsidered
16:43:58 <dustymabe> I think I'm not -1
16:44:03 <dustymabe> s/not/now
16:44:36 <red_beard> so we're currently in a situation where it's broken as is (expected functionality doesn't work out of the box) and the needed change will break _other_ things.
16:44:54 <jlebon> i think the "if they get ahold of a cgroup file system" is an important distinction
16:44:55 <red_beard> so which is the greater evil?
16:45:17 <dustymabe> red_beard: what is the "the needed change will break _other_ things." part ?
16:45:29 <cyberpear> making the system less secure
16:45:45 <dustymabe> red_beard: is that it ^^ ?
16:45:51 <jlebon> i wonder how common systemd in containers really is in practice.  clearly has use cases, though it's not the primary path
16:46:07 <cyberpear> My vote is to have it turned off by default, but clearly document how to enable it for folks using systemd in containers
16:46:08 <jlebon> for a while it never really worked right in Fedora
16:46:11 * cyberpear uses systemd in containers
16:46:39 <dustymabe> cyberpear: right. so you're vote is the current status quo + add docs
16:46:44 <red_beard> i'd assume so.  i'm trying to fully comprehend the scope of what's happening.  my initial reading was to have systemd _run_ containers (aka systemd-machined)
16:46:44 <dustymabe> which I think is where I am too
16:46:54 <red_beard> but now re-reading it see it's systemd inside of the container itself
16:47:00 <dustymabe> red_beard: right
16:47:02 <red_beard> which.... is also a use case with systemd-machined
16:47:02 <cyberpear> red_beard: yes, systemd inside a container
16:47:04 <dustymabe> systemd inside the container
16:47:05 <cyberpear> much less common
16:47:57 <dustymabe> yeah I don't really think enabling this will "break" other things, but I do think the security implications (which we didn't fully understand before) are significant
16:48:05 <dustymabe> and are a good enough reason to reject this by default
16:48:27 <jlebon> #proposed due to the security implications, we would rather keep container_manage_cgroup off. we should discuss with SELinux folks on a better path. meanwhile, we should document how to enable it for those who really want it
16:48:34 <cyberpear> right. relaxing the security doesn't generally break anything, just exposes future risk of compromise
16:48:58 <dustymabe> jlebon: +1
16:49:12 <dustymabe> once we vote on that I think there is a brief followup discussion we should have
16:49:18 <red_beard> out of curiosity, where will the documentation for this live?
16:49:28 <cyberpear> +1 to proposed
16:49:28 <lorbus> I'm +1 on this. systemd in containers should be avoided if possible imo
16:49:42 <jlebon> red_beard: why not https://docs.fedoraproject.org/en-US/fedora-coreos/ ?
16:50:04 * cyberpear uses systemd in containers as lightweight VMs for CI testing
16:51:01 <jlebon> red_beard: +1 for the above proposal?
16:51:27 * dustymabe checking - am I a chair ?
16:51:29 <dustymabe> #chair
16:51:29 <zodbot> Current chairs: cyberpear dustymabe dustyweb83 jlebon lorbus miabbott red_beard skunkerk
16:51:30 <red_beard> jlebon: documentation is not an area where the project is thriving and "put it in the docs" becomes a dumping ground for esoteric answers
16:51:32 <dustymabe> oh ok, good
16:51:59 <red_beard> i'd assume https://docs.fedoraproject.org/en-US/fedora-coreos/running-containers/ ?
16:52:14 <jlebon> red_beard: that's fair. though i'd like to think we're slowly getting there :)
16:52:33 <jlebon> i always try to add to documentation when answering questions from the community
16:52:38 <dustymabe> red_beard: we could definitely use a docs champion
16:52:53 <dustymabe> jlebon: yeah you do. thanks for that
16:53:32 <jlebon> red_beard: yeah, i think that page is a good candidate
16:54:27 * dustymabe waits to start followup discussion
16:54:50 * red_beard gives the thumbs up
16:55:01 <jlebon> #agreed due to the security implications, we would rather keep container_manage_cgroup off. we should discuss with SELinux folks on a better path. meanwhile, we should document how to enable it for those who really want it
16:55:09 <jlebon> dustymabe: shoot
16:55:40 <dustymabe> ok so cyberpear I think your suggestion in https://github.com/coreos/fedora-coreos-config/pull/291 looks good as a possible short term solution
16:55:56 <dustymabe> although obviously the ignition bug is a PITA
16:56:15 <dustymabe> maybe we can continue the discussion about that in the PR itself
16:56:23 <cyberpear> +1
16:57:01 <dustymabe> regarding the longer term solution there are some real issues we've been hitting with how selinux works and how a user wants to configure it on FCOS
16:57:06 <cyberpear> two versions of the service (on and off) because most bools are off by default, but a handful are on by default
16:57:23 <dustymabe> we are going to try to talk to the SELinux team about these
16:57:38 <dustymabe> to see if there is a better long term solution
16:57:42 <cyberpear> right, if you want to do anything but tweak bools, I think it's an actual policy change wa1em / semanage`
16:58:01 <cyberpear> *w/ `semanage`
16:58:05 <dustymabe> also jlebon I heard you mention it would be nice if the selinux boolean for this cgroup stuff was configurable per container
16:58:19 <dustymabe> i.e. you only open it up for containers that actually run systemd in a container
16:58:24 <jlebon> dustymabe: right
16:58:25 <dustymabe> is that something we should discuss too
16:58:29 <dustymabe> with the selinux team
16:58:43 <jlebon> well, it wouldn't be an seboolean, maybe a container label or something?
16:58:47 <cyberpear> sounds like udica
16:58:48 <dustymabe> right
16:58:58 <jlebon> probably worth discussing with them, yeah
16:59:02 <dustymabe> cyberpear: you might be right.. /me doesn't know much about udica
16:59:36 <cyberpear> or udica could help develop the appropriate policy, anyway -- it's for creating policies more permissive than the default, but less permissive than spc_t
16:59:46 <dustymabe> +1
16:59:57 <dustymabe> ok cool I think we've wrapped up the points I wanted to bring up
17:00:18 <jlebon> #topic manifest: Add NetworkManager-team and teamd
17:00:23 <jlebon> #link https://github.com/coreos/fedora-coreos-config/pull/289
17:00:41 <jlebon> there's been a request to add built-in teaming support to FCOS
17:00:51 <jlebon> this is relevant for RHCOS
17:01:06 <cyberpear> +1 for the support
17:01:12 * cyberpear checking MB disk impact now
17:01:38 <jlebon> cyberpear: i eyeballed it to ~1M, but a sanity-check would be good
17:02:39 <red_beard> is there a proposal for the ignition spec to support this?
17:02:54 <cyberpear> 1.7M, but I didn't check how much of that is docs
17:02:58 <dustymabe> red_beard: ignition spec to specifically support teaming ?
17:03:00 <jlebon> red_beard: i don't think so
17:03:14 <jlebon> it would be configured via NM keyfiles under storage.files
17:03:45 <red_beard> nm, i see network support was completely removed from the v3 ignition spec
17:04:16 <lorbus> networkd support, yes.
17:04:28 <lorbus> NM keyfiles are now just standard ignition files
17:04:43 <dustymabe> I said this in the ticket too, but +1 from me on this one.. mostly because #networking
17:04:59 <jlebon> as mentioned in the ticket, having it built-in isn't a hard requirement, so there's some overlap with the "OS extensions" discussions here. but it would make provisioning easier if it were
17:05:28 <jlebon> cyberpear: yeah, that's likely inflated by docs
17:05:38 <miabbott> i'm in favor of including teaming support
17:05:43 <cyberpear> apparently it's the whole 1.7M even w/o docs and w/ just C `%_install_langs`
17:06:53 <jlebon> #proposed we will ship baked-in support for teaming in FCOS to make network configuration easier on first boot
17:07:55 <dustymabe> +1 considering the implementation of extensions will most likely need networking and having a single networking config is more straitforward
17:07:58 <cyberpear> +1 to proposed
17:08:09 <lorbus> +1
17:08:36 <miabbott> +1
17:08:55 <jlebon> #agreed we will ship baked-in support for teaming in FCOS to make network configuration easier on first boot
17:09:27 <jlebon> and with that, i think we're ready for
17:09:31 <jlebon> #topic Open Floor
17:09:47 <jlebon> anything anyone wants to bring up/highlight?
17:10:12 * dustymabe has been AFK for the last 6 days or so. sorry if you've needed me. please ping me in IRC now if there is something that needs my attention
17:10:20 <dustymabe> i'll slowly be working through notifications
17:11:07 <dustymabe> skunkerk: welcome to your first FCOS community meeting :)
17:11:15 <miabbott> skunkerk++
17:11:27 <dustymabe> c_insighter: is this your first as well?
17:12:12 <dustymabe> maybe we scared them off :(
17:12:34 <jlebon> #info there's been some discussions re. reworking ignition config fetching on QEMU: https://github.com/coreos/ignition/issues/928
17:13:55 <jlebon> though it's the primary way to test FCOS locally, this shouldn't affect developer workflows *too* much if one just sticks with `cosa run`/`kola spawn`
17:14:04 <dustymabe> +1
17:14:05 <cyberpear> yeah, `systemd-analyze plot` shows that the first boot takes 20 seconds on my laptop, from `cosa run`
17:14:06 <jlebon> it will affect the libvirt path though
17:14:12 <dustymabe> thanks jlebon for driving that discussion
17:14:42 <dustymabe> cyberpear: in your mind is that good or bad?
17:15:15 <dustymabe> RIP dustyweb83
17:15:28 <cyberpear> it's slower than I would hope for a VM, but I'd need to test a anaconda-installed VM for comparison
17:15:44 <dustymabe> yeah I don't think we've done any sort of analysis there
17:15:48 <cyberpear> (most of that time (14s) is spend in the initrd)
17:15:59 <dustymabe> though I will note that comparing to an anaconda installed VM is not quite the same
17:16:07 <dustymabe> because of ignition
17:16:15 <cyberpear> otherwise, udev-settle takes 2s, and is the single longest blocking after the initrd
17:16:21 <cyberpear> right
17:17:01 <jlebon> any other thoughts?
17:17:30 <jlebon> closing the meeting in 1 min otherwise :)
17:17:35 <dustymabe> +1
17:17:37 <cyberpear> (for reference, it takes 90s to kickstart a VM on the same laptop from scratch into a minimal install, most of which is spend by dracut)
17:18:36 <jlebon> #endmeeting