16:30:03 <dustymabe> #startmeeting fedora_coreos_meeting
16:30:03 <zodbot> Meeting started Wed Nov 20 16:30:03 2019 UTC.
16:30:03 <zodbot> This meeting is logged and archived in a public location.
16:30:03 <zodbot> The chair is dustymabe. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:30:03 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:30:03 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:30:09 <dustymabe> #topic roll call
16:30:14 <dustymabe> .hello2
16:30:15 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:30:16 <ajeddeloh> .hello2
16:30:17 <zodbot> ajeddeloh: ajeddeloh 'Andrew Jeddeloh' <andrew.jeddeloh@redhat.com>
16:30:23 <walters> .hello2
16:30:24 <zodbot> walters: walters 'Colin Walters' <walters@redhat.com>
16:30:39 <jlebon> .hello2
16:30:40 <zodbot> jlebon: jlebon 'None' <jonathan@jlebon.com>
16:30:48 <sayan> .hello sayanchowdhury
16:30:49 <zodbot> sayan: sayanchowdhury 'Sayan Chowdhury' <sayan.chowdhury2012@gmail.com>
16:30:51 <kaeso[m]> .hello lucab
16:30:52 <zodbot> kaeso[m]: lucab 'Luca Bruno' <lucab@redhat.com>
16:31:11 <walters> jlebon: "None" 😀
16:31:32 <ksinny> .hello sinnykumari
16:31:33 <zodbot> ksinny: sinnykumari 'Sinny Kumari' <ksinny@gmail.com>
16:31:49 <walters> love when the programming language implementation details leak out, like `null` on websites from JS
16:32:06 <walters> would happen a lot less of course if these languages had Option<>
16:32:42 <dustymabe> #chair ajeddeloh jlebon sayan kaeso[m] walters ksinny
16:32:42 <zodbot> Current chairs: ajeddeloh dustymabe jlebon kaeso[m] ksinny sayan walters
16:32:51 <jlebon> walters: heh. i've given up trying to figure out where zodbot gets that from
16:33:50 <kaeso[m]> walters: Some("jlebon")?
16:34:22 <dustymabe> welcome all - it's been a while since we've had a meeting. glad to be back here in the meeting channel
16:34:32 <dustymabe> moving on to topics
16:34:39 <dustymabe> #topic python3 getting pulled in by crypto-policies
16:34:45 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/280
16:34:57 <dustymabe> I added the meeting label to this ticket
16:35:28 <dustymabe> basically it looks like in the BZ the action item is on us to submit a patch to get python out of crypto policies for our purposes
16:35:49 <dustymabe> so.. we have a path forward at least
16:36:16 <dustymabe> but the reason I brought up this ticket is because we have switched to f31 in testing-devel and it's been almost a month since our last preview release
16:36:27 <dustymabe> so we need to do a stable release soon
16:36:36 <dustymabe> but.. is it OK that python is still in for now
16:37:12 <dustymabe> any thoughts on "ship or not with python in"?
16:37:26 <dustymabe> if no free form thoughts we can possibly vote one way or the other
16:37:30 <jlebon> i think ajeddeloh started on a patch for this
16:37:40 <bgilbert> .hello2
16:37:43 <zodbot> bgilbert: bgilbert 'Benjamin Gilbert' <bgilbert@backtick.net>
16:37:46 <dustymabe> #chair bgilbert
16:37:46 <zodbot> Current chairs: ajeddeloh bgilbert dustymabe jlebon kaeso[m] ksinny sayan walters
16:37:48 <ajeddeloh> I haven't actually started the patch, just determined it can be done
16:37:56 <ajeddeloh> it fell off my radar
16:38:39 <bgilbert> in principle I'm okay with Python in the preview, but if it leaks into stable without something to make sure user scripts don't use it, that's not ideal
16:38:51 <jlebon> dustymabe: i don't think it should be a blocker
16:39:36 <dustymabe> bgilbert: agreed
16:39:50 <ksinny> If we can split the package, it will be nice. Becasue when stable goes out and more people strats using the FCOS, they may try running python script on host and would expect that this will be part of host in future update as well
16:40:11 <kaeso[m]> my gut feeling is that, at this specific point, priority-wise it's f31 > python-less
16:40:16 <dustymabe> yep. we definitely want to split the package
16:40:55 <dustymabe> #proposed put out an f31 release this week even though python packages are still in, split out crypto policies later to get python back out
16:41:12 <dustymabe> ack/nack
16:41:25 <jlebon> +1
16:41:31 <bgilbert> +0.5
16:41:37 <ajeddeloh> abstain?
16:41:41 <ajeddeloh> +0?
16:42:19 <dustymabe> .5 average - are we glass half full or glass half empty people
16:42:35 <kaeso[m]> .55
16:42:38 <bgilbert> ooh
16:42:44 <dustymabe> :)
16:42:47 <dustymabe> pass!
16:42:55 <dustymabe> #agreed put out an f31 release this week even though python packages are still in, split out crypto policies later to get python back out
16:43:23 <dustymabe> anybody want to volunteer to do the release this week?
16:43:41 <dustymabe> primary (does the work) - secondary (review the work)
16:44:20 <jlebon> i nominate myself to be secondary and help guide if someone who hasn't done a release yet wants to try :)
16:44:44 * dustymabe waits 20 seconds
16:45:46 <dustymabe> ok I'll rock primary
16:46:09 <dustymabe> #topic cgroups v2 strategy
16:46:13 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/292
16:46:22 <dustymabe> I can't remember if we've brought this up before in a meeting
16:46:30 <ajeddeloh> we have
16:46:36 <dustymabe> ok cool
16:46:45 <bgilbert> https://github.com/coreos/fedora-coreos-tracker/issues/292#issuecomment-543887262
16:47:02 <dustymabe> +1
16:47:05 <ajeddeloh> iirc the conclusion was "not yet, switch at some point in the future, it's going to suck, but theres no getting around that"
16:47:15 <dustymabe> in that case, can we close this ticket
16:47:22 <dustymabe> any documentation that needs to be added?
16:47:26 <dustymabe> maybe some fcct sugar ?
16:47:38 <ajeddeloh> +1
16:48:10 <kaeso[m]> isn't there some active work we have to do to opt-out f31 cgroupv2 defaults?
16:48:33 <dustymabe> kaeso[m]: we are setting the kernel arg
16:48:40 <dustymabe> systemd.unified_cgroup_hierarchy=0
16:48:46 <jlebon> we're opting out today: https://github.com/coreos/fedora-coreos-config/blob/ee79fe42d5d86f1b1491e1370de013523e189f76/image.yaml#L10
16:49:46 <kaeso[m]> ack, great
16:50:07 <dustymabe> so.. close this ticket?
16:50:14 <dustymabe> is there an existing request for fcct sugar for this?
16:50:34 <ajeddeloh> no
16:50:39 <bgilbert> do we want sugar for this in particular?
16:50:44 <kaeso[m]> and, later on, dropping it from the compose will affect updated machines too?
16:50:48 <bgilbert> seems like generic karg sugar is a good middle ground
16:51:07 <dustymabe> bgilbert: that's worth discussing
16:51:17 <bgilbert> kaeso[m]: I think we'd want to leave existing machines alone?
16:51:24 <jlebon> kaeso[m]: it won't
16:51:26 <dustymabe> bgilbert: yeah I agree
16:52:29 <dustymabe> ok so no new action item there.. cgroups v1/v2 changes won't happen on upgrde
16:52:46 <dustymabe> regarding fcct sugar. it seems like there are two options
16:52:53 <dustymabe> - special sugar for cgroups v1/v2
16:53:04 <kaeso[m]> let me rephrase: how do we plan to undo the karg for f3x?
16:53:05 <dustymabe> - generic sugar for kargs + documentation specific to cgroup v1/v2
16:54:22 <bgilbert> kaeso[m]: at some point, new installs will switch to v2
16:55:01 <bgilbert> dustymabe: yup.  +1 to option 2.
16:55:15 <bgilbert> let's not sugar every specific problem we ever have
16:55:28 <bgilbert> esp. since karg sugar gets us most of the way there
16:56:02 <dustymabe> I'm +1 to option 2, but could see the value in option 1
16:56:10 <dustymabe> any other thoughts before we choose?
16:56:18 <kaeso[m]> bgilbert: and upgraded nodes? do they automatically v1->v2 at some point or they stick at v1 unless manual intervention?
16:56:50 <bgilbert> kaeso[m]: automatic would need to happen much later and with lots of notice
16:56:58 <bgilbert> i.e. treat it as a breaking change
16:57:16 <bgilbert> (hopefully it isn't one, but yeah)
16:57:29 <jlebon> assuming the *only* knob required is the karg (which AFAIK is the case), then yeah option 2 is cleaner
16:57:38 <bgilbert> part of the problem there is distinguishing an old default from explicit user configuration
16:57:56 <jlebon> sometimes some kargs need more work, then sugar might be nice, like fips=1
16:58:15 <dustymabe> kaeso[m]: this is where something like barriers would be nice (i.e. being able to force a user to reprovision after certain amounts of time)
16:59:14 <kaeso[m]> yup, just s/barrier/deadend/
16:59:19 <bgilbert> I don't see a problem in carrying v1 for a long time
16:59:26 <bgilbert> I doubt that code will rot quickly
16:59:38 <dustymabe> bgilbert: yeah agree. I was applying this problem more generically
16:59:46 <bgilbert> dustymabe: ah, ok
17:00:06 <jlebon> dropping it from upgraded nodes will be cumbersome to do until we move kargs "ownership" to inside the commit as in that ostree patch
17:00:23 <jlebon> which would also make option 2 much nicer to implement
17:01:05 <kaeso[m]> jlebon: https://github.com/ostreedev/ostree/pull/1836?
17:01:12 <dustymabe> ok so let's say:
17:01:21 <jlebon> kaeso[m]: +1
17:01:55 <dustymabe> #proposed this ticket is mostly done but we'll try to create docs and use fcct kargs support to show how to set it to v1 or v2
17:02:16 <bgilbert> +1
17:02:30 <ajeddeloh> +1[
17:03:13 <dustymabe> #agreed this ticket is mostly done but we'll try to create docs and use fcct kargs support to show how to set it to v1 or v2
17:03:31 <dustymabe> #topic Open Floor
17:03:40 <dustymabe> anything anyone else would like to bring up?
17:05:20 <kaeso[m]> (nothing from my side)
17:05:40 <bgilbert> not from me
17:07:03 <jlebon> <None> here
17:07:06 <dustymabe> #endmeeting