fedora_coreos_meeting
LOGS
16:30:08 <dustymabe> #startmeeting fedora_coreos_meeting
16:30:08 <zodbot> Meeting started Wed Oct 12 16:30:08 2022 UTC.
16:30:08 <zodbot> This meeting is logged and archived in a public location.
16:30:08 <zodbot> The chair is dustymabe. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:30:08 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:30:08 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:30:13 <dustymabe> #topic roll call
16:30:14 <dustymabe> .hi
16:30:15 <zodbot> dustymabe: Something blew up, please try again
16:30:18 <zodbot> dustymabe: An error has occurred and has been logged. Please contact this bot's administrator for more information.
16:30:35 <dustymabe> .hellomynameis dustymabe
16:30:36 <zodbot> dustymabe: Something blew up, please try again
16:30:39 <zodbot> dustymabe: An error has occurred and has been logged. Please contact this bot's administrator for more information.
16:30:42 <dustymabe> yep - zodbot is borked
16:32:11 * dustymabe checks his watch
16:32:14 <jlebon> .hello2
16:32:15 <zodbot> jlebon: Something blew up, please try again
16:32:18 <zodbot> jlebon: An error has occurred and has been logged. Please contact this bot's administrator for more information.
16:32:24 <dustymabe> 👋 jlebon
16:32:27 <dustymabe> #chair jlebon
16:32:27 <zodbot> Current chairs: dustymabe jlebon
16:32:29 * jlebon waves
16:32:45 <bgilbert> .hi
16:32:46 <zodbot> bgilbert: Something blew up, please try again
16:32:49 <zodbot> bgilbert: An error has occurred and has been logged. Please contact this bot's administrator for more information.
16:32:59 <bgilbert> .chair bgilbert
16:32:59 <zodbot> bgilbert is seated in a chair with a nice view of a placid lake, unsuspecting that another chair is about to be slammed into them.
16:33:05 <dustymabe> #chair bgilbert
16:33:05 <zodbot> Current chairs: bgilbert dustymabe jlebon
16:33:12 <dustymabe> watch out bgilbert!
16:33:19 <marmijo> .hi
16:33:20 <zodbot> marmijo: Something blew up, please try again
16:33:23 <zodbot> marmijo: An error has occurred and has been logged. Please contact this bot's administrator for more information.
16:33:24 <dustymabe> #chair marmijo
16:33:24 <zodbot> Current chairs: bgilbert dustymabe jlebon marmijo
16:34:26 <dustymabe> small crowd today
16:34:29 <gursewak> .hi
16:34:30 <zodbot> gursewak: Something blew up, please try again
16:34:32 <dustymabe> #chair gursewak
16:34:32 <zodbot> Current chairs: bgilbert dustymabe gursewak jlebon marmijo
16:34:32 <zodbot> gursewak: An error has occurred and has been logged. Please contact this bot's administrator for more information.
16:34:45 <dustymabe> #topic Action items from last meeting
16:34:51 <dustymabe> Looks like there were no action items from last meeting!
16:35:07 <dustymabe> though I do wonder if walters managed to start on breaking up the Fedora Change we discussed
16:35:23 * dustymabe will move to topics here soon
16:36:05 <dustymabe> #topic Conference: Kubernetes Community Days France 2023
16:36:10 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/1319
16:36:44 <dustymabe> travier posted this as an FYI and also to collaborate with other people interested in going and submitting talks
16:37:02 <spresti[m]> .hi
16:37:02 <davdunc[m> .hello davdunc
16:37:03 <lorbus> .hi
16:37:04 <zodbot> spresti[m]: Something blew up, please try again
16:37:07 <zodbot> davdunc[m: Something blew up, please try again
16:37:10 <zodbot> lorbus: Something blew up, please try again
16:37:13 <zodbot> spresti[m]: An error has occurred and has been logged. Please contact this bot's administrator for more information.
16:37:16 <zodbot> davdunc[m: An error has occurred and has been logged. Please contact this bot's administrator for more information.
16:37:19 <zodbot> lorbus: An error has occurred and has been logged. Please contact this bot's administrator for more information.
16:37:27 <dustymabe> #info some of our contributors/users will be at Kubernetes Community Days France 2023 - please collaborate in the proposal if you're interested
16:37:34 <dustymabe> #chair spresti[m] davdunc[m lorbus
16:37:34 <zodbot> Current chairs: bgilbert davdunc[m dustymabe gursewak jlebon lorbus marmijo spresti[m]
16:37:50 <jmarrero> .hi
16:37:50 <walters> I thought about it but it wasn't clear to me exactly how so I just submitted it as is for now
16:37:50 <zodbot> jmarrero: Something blew up, please try again
16:37:54 <zodbot> jmarrero: An error has occurred and has been logged. Please contact this bot's administrator for more information.
16:37:54 * dustymabe is reminded it's almost 2023
16:38:00 <davdunc> .hello2
16:38:01 <zodbot> davdunc: Something blew up, please try again
16:38:04 <zodbot> davdunc: An error has occurred and has been logged. Please contact this bot's administrator for more information.
16:38:52 <copperi[m]> .hello copperi
16:38:52 <lorbus> I will be submitting a talk on OKD, hope to see some of you there :) Thanks for the pointer travier
16:38:52 <zodbot> copperi[m]: Something blew up, please try again
16:38:55 <zodbot> copperi[m]: An error has occurred and has been logged. Please contact this bot's administrator for more information.
16:38:58 <lorbus> .hello2
16:38:59 <zodbot> lorbus: Something blew up, please try again
16:39:02 <zodbot> lorbus: An error has occurred and has been logged. Please contact this bot's administrator for more information.
16:39:38 <lorbus> oof it looks like the Matrix bridge is acting up again today, and good ol' zod too
16:39:44 <dustymabe> walters we had some suggestions in the meeting last week, but it might be useful to have a dedicated session on the topic of breaking up the proposal
16:40:00 <davdunc> eiifccujiniuntetcdhhbeibrftdjejiflenfjnthibb
16:40:10 <davdunc> achoo!
16:40:29 <dustymabe> gezuntheit
16:40:34 <walters> one nontechnical thing is I find trying to context switch in Mediawiki syntax really painful
16:40:43 <aaradhak> .hi
16:40:44 <zodbot> aaradhak: Something blew up, please try again
16:40:47 <zodbot> aaradhak: An error has occurred and has been logged. Please contact this bot's administrator for more information.
16:40:55 <dustymabe> #chair aaradhak
16:40:55 <zodbot> Current chairs: aaradhak bgilbert davdunc[m dustymabe gursewak jlebon lorbus marmijo spresti[m]
16:41:11 <dustymabe> #chair copperi[m]
16:41:11 <zodbot> Current chairs: aaradhak bgilbert copperi[m] davdunc[m dustymabe gursewak jlebon lorbus marmijo spresti[m]
16:41:31 <mnguyen_> im here but will spare zodbot
16:41:36 <dustymabe> #chair mnguyen_
16:41:36 <zodbot> Current chairs: aaradhak bgilbert copperi[m] davdunc[m dustymabe gursewak jlebon lorbus marmijo mnguyen_ spresti[m]
16:41:42 <dustymabe> ok i'll move on to the next topic
16:41:50 <dustymabe> #topic Move Ignition glue to a package
16:42:00 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/1311
16:42:07 <walters> I do notice only one person on this team has put their name on it
16:42:22 <walters> (other)
16:43:24 <dustymabe> anyone want to introduce the current topic
16:43:42 <jmarrero> I am here too :D
16:44:13 <bgilbert> walters, you brought this one forward, go for it
16:45:20 <walters> Fedora IoT wants to use Ignition now, they use Image Builder which can only take RPMs as input, the dracut modules have lots of nontrivial logic and glue (particularly with ostree which they also use)
16:46:49 <walters> I think that's it?
16:48:16 <jlebon> this sounds reasonable to me, but a big question is bgilbert's around whether this implies moving the code or not
16:48:21 <bgilbert> IMO the Ignition glue in f-c-c has gradually turned into technical debt
16:48:31 <walters> Oh actually this also touches on https://github.com/openshift/release/pull/31973 which is "OKD wants bits of the overlay from openshift/os"
16:48:55 <bgilbert> I'd like us to move to a better architecture for it, but I think we should probably package it as-is first and see what we learn
16:49:14 <jlebon> i would *really* hope at least for us we keep the status quo of just doing PRs to ship stuff
16:49:19 <walters> hmm, debt in what way?
16:49:39 <bgilbert> walters: everyone who tries to add Ignition to their distro runs into the brick wall of the glue code
16:49:41 <bgilbert> pretty much immediately
16:49:50 <walters> ah ok yeah
16:49:59 <bgilbert> it's in f-c-c because it's specific to CoreOS in some ways, but no one wants to reimplement all of that
16:50:25 <bgilbert> if we package it up in the short term, I'd lean toward not using that package in CoreOS
16:50:50 <walters> dracut modules are already on their own really difficult to debug black art, even aside from the complexity involved in these
16:50:56 <bgilbert> walters: yep
16:52:08 <bgilbert> walters, are the IoT folks going to identify someone to work with us?  I don't think this'd work well if we're just throwing a package over the wall
16:52:33 <jlebon> bgilbert: +1
16:53:31 <walters> We probably should have summoned one of them here, I don't know; but I suspect the answer is that if we just did the mechanics of packaging it, it'd at least unblock starting integration work there and they could e.g. submit PRs that fix things
16:53:42 <bgilbert> fair
16:54:09 * miabbott waves
16:54:20 <dustymabe> hey stranger
16:54:23 <bgilbert> I'm not sure it's 100% clear what "it" is though.  there's a lot of dracut glue with a varying degree of connection to Ignition and CoreOS
16:54:39 <jlebon> if we're not going to use it ourselves, then I think IoT folks should own the RPM
16:54:48 <dustymabe> jlebon: +1
16:54:50 <bgilbert> so I think I'd much rather engage with a technical IoT person before any work is done
16:55:03 <bgilbert> some of it will depend on which pieces they want to support
16:55:17 <walters> hmm I was more thinking we package the stuff, and replace what we're doing in the overlay with it, hence verifying it works
16:55:29 <miabbott> i'd probably ask antonio to help from the iot/edge side; he has the most familiarity with ignition.  but longer term, i'd like to have him pass on some of that knowledge/responsibility to someone else on our team
16:55:44 <dustymabe> IOW we use it ourselves, but we lose quick PR workflow
16:56:53 <bgilbert> walters: yeah, that feels counterproductive to me.  not just for the "what to package" question, or losing quick iteration just when we'll probably want it most, but also because just moving files to an RPM doesn't prove much
16:57:02 <dustymabe> if we lose quick PR workflow we also need to be careful about when RPMs land in our streams (it's decoupled now)
16:57:58 <walters> Hmm, OK.
16:58:11 <bgilbert> we can always make larger moves later if it makes sense
16:58:35 <walters> Certainly short term seems totally viable to me to do as you suggest, iterate on any fixes and sharing, then later try to use the RPM instead of overlay when it's more stable
16:59:04 <bgilbert> walters: I kinda hope we can skip that middle step and refactor this into upstream Ignition, but that might be optimistic
16:59:46 <walters> Ah, I see.  Yeah
17:00:33 <bgilbert> miabbott: would it make sense to loop in both Antonio and someone else from the start?
17:00:45 <bgilbert> or is that too ambitious
17:01:21 <miabbott> bgilbert: i'll need to sort out the "someone else", but i think spreading the knowledge/responsibility from the start is wise
17:01:27 <bgilbert> +1
17:01:27 <dustymabe> in order to have the right relationship with that team, I think it's the only way to do it
17:01:44 <jlebon> bgilbert: i have a concern putting it in Ignition and de-CoreOS-ifying it will mean yet more API surface to document and get right. if it's ostree-specific I think that'd help, but doesn't help other integrators.
17:02:01 <dustymabe> anyone want to come up with a #proposed ?
17:02:55 <bgilbert> jlebon: I'm thinking of it as a pretty heavyweight refactor.  I think we should seriously rethink how we ship that code and how it gets customized
17:03:13 <bgilbert> it's a major blocker to integrating Ignition into distros, which is not great
17:03:31 <jlebon> bgilbert: gotcha
17:03:45 <dustymabe> right, we should just think of IoT as another distro at this point - they would have the same problems anyone would
17:04:29 <walters> One thing that might help is actually writing it in Go and including it in the Ignition binary itself, configured at build time (e.g. use ostree configs, etc.)
17:04:51 <bgilbert> walters: that's the direction I'm leaning.  though 100% build time may not work, since different Fedora editions want different things
17:05:19 <walters> I'd hope we can drive that set of things to zero, but yes
17:05:52 <walters> a definite sticking point now is IoT wants to retain their custom "LUKS reencrypt in place" flow
17:06:06 <walters> which I still see as a special case optimization we could make too
17:06:25 <bgilbert> working on a proposed
17:06:34 <dustymabe> bgilbert++
17:07:36 <miabbott> walters: maybe i have it wrong, but i don't think we "want to" retain that flow; i think we are more constrained to that flow because of the resource limitations for IoT devices
17:08:04 <bgilbert> #proposed We will work with the IoT team to help create an RPM (sub)package for the Ignition fedora-coreos-config glue needed by IoT.  Initially we'll package the files directly from fedora-coreos-config, and CoreOS itself will not ship the package.  If adjustments are needed to the glue, we'll make them upstream in fedora-coreos-config.
17:08:38 <dustymabe> bgilbert: do we want to include anything about the refactor in there?
17:08:44 <walters> miabbott: seems to be equivalent statements in practice?  I'd note the optimization makes sense for smaller cloud images too
17:08:45 <bgilbert> was just thinking that, yeah
17:09:28 <walters> +1 to proposed
17:09:37 <bgilbert> add: After we gain some experience, we'll re-evaluate where the code should live and what sort of refactoring should be done.
17:09:55 <dustymabe> ack
17:10:11 <jlebon> ack
17:10:29 <bgilbert> +1 to my own
17:10:32 <bgilbert> miabbott?
17:10:33 <dustymabe> :)
17:10:34 <copperi[m]> ack
17:10:36 <miabbott> ack
17:10:42 <dustymabe> bgilbert: want to do #agreed too?
17:10:44 <bgilbert> yup
17:11:05 <bgilbert> #agreed We will work with the IoT team to help create an RPM (sub)package for the Ignition fedora-coreos-config glue needed by IoT.  Initially we'll package the files directly from fedora-coreos-config, and CoreOS itself will not ship the package.  If adjustments are needed to the glue, we'll make them upstream in fedora-coreos-config.  After we gain some experience, we'll re-evaluate where the code should live and what sort of refactoring
17:11:05 <bgilbert> should be done.
17:11:13 <bgilbert> hmm
17:11:14 <bgilbert> #undo
17:11:14 <zodbot> Removing item from minutes: AGREED by bgilbert at 17:11:05 : We will work with the IoT team to help create an RPM (sub)package for the Ignition fedora-coreos-config glue needed by IoT.  Initially we'll package the files directly from fedora-coreos-config, and CoreOS itself will not ship the package.  If adjustments are needed to the glue, we'll make them upstream in fedora-coreos-config.  After we gain some experience, we'll re-evaluate where the code should live and what sort of refactoring
17:11:21 <dustymabe> bgilbert: it's normal don't worry
17:11:34 <bgilbert> does the whole message carry into the minutes?
17:11:47 <dustymabe> i think either IRC or your client (mine does) breaks up the line
17:12:08 <dustymabe> bgilbert: not 100% sure - but it will make it into the comment I post in the issue
17:12:46 <bgilbert> #agreed We'll work with the IoT team to help create an RPM (sub)package for the Ignition fedora-coroes-config glue needed by IoT.  Initially we'll package the files directly from f-c-c, and CoreOS itself will not ship the package.  If adjustments are needed to the glue, we'll make them upstream in f-c-c.  After we gain some experience, we'll re-evaluate where the code should live and what sort of refactoring should be done.
17:12:57 <dustymabe> :) fixed!
17:13:13 <dustymabe> #topic open floor
17:13:13 <bgilbert> it seems we can't agree on anything too complicated :-)
17:13:29 <dustymabe> anyone have anything for open floor today?
17:13:58 <dustymabe> copperi[m]: was wondering if you were able to look at https://github.com/coreos/fedora-coreos-tracker/issues/1291 more closely?
17:14:15 <dustymabe> it would be a huge help if you were able to be a co-maintainer there
17:15:00 <copperi[m]> I have contacted gotmax and am in progress with it.
17:15:09 <dustymabe> copperi[m]++
17:15:17 <dustymabe> that's awesome! thank you
17:15:24 <dustymabe> do you mind posting an update in the ticket?
17:15:46 <copperi[m]> sure
17:15:50 <bgilbert> copperi[m]++
17:16:03 <dustymabe> any other things to discuss before we close out?
17:16:55 <gotmax> containerd and moby-engine have been orphaned. I haven't decided whether I'm going to pick them up.
17:17:37 <dustymabe> gotmax: thank you for the update
17:17:49 <gotmax> I'll probably wait a couple weeks to to give others a chance before picking them up myself.
17:18:12 <dustymabe> what does the timeline look like on that? how long in orphan before they get retired?
17:19:53 <bgilbert> six weeks: https://docs.fedoraproject.org/en-US/fesco/Policy_for_orphan_and_retired_packages/
17:21:10 <gotmax> Correct
17:21:38 <dustymabe> cool - thanks for the updates. at least in the very least copperi[m] is willing to help co-maintain
17:21:41 <dustymabe> again, thanks to you both
17:21:50 <dustymabe> any other topics before closing out the meeting?
17:22:37 <bgilbert> (looks like the clock started a week ago: https://pagure.io/fesco/issue/2867#comment-819913)
17:23:46 <dustymabe> #endmeeting