16:30:52 <dustymabe> #startmeeting fedora_coreos_meeting
16:30:52 <zodbot> Meeting started Wed Jun  3 16:30:52 2020 UTC.
16:30:52 <zodbot> This meeting is logged and archived in a public location.
16:30:52 <zodbot> The chair is dustymabe. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:30:52 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:30:52 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:30:56 <dustymabe> #topic roll call
16:30:57 <cyberpear> o/
16:30:58 <jlebon> .hello2
16:30:59 <zodbot> jlebon: jlebon 'None' <jonathan@jlebon.com>
16:31:01 <cyberpear> .hello2
16:31:02 <zodbot> cyberpear: cyberpear 'James Cassell' <fedoraproject@cyberpear.com>
16:31:06 <skunkerk> .hello sohank2602
16:31:07 <zodbot> skunkerk: sohank2602 'Sohan Kunkerkar' <skunkerk@redhat.com>
16:31:12 <kparal> .hello2
16:31:12 <coremodule> .hello2
16:31:15 <zodbot> kparal: kparal 'Kamil Páral' <kparal@redhat.com>
16:31:17 <davdunc> .hello2
16:31:17 <slowrie> .hello2
16:31:18 <zodbot> coremodule: coremodule 'Geoffrey Marr' <gmarr@redhat.com>
16:31:21 <zodbot> davdunc: davdunc 'David Duncan' <davdunc@amazon.com>
16:31:25 <zodbot> slowrie: slowrie 'Stephen Lowrie' <slowrie@redhat.com>
16:31:38 <bgilbert> .hello2
16:31:38 <zodbot> bgilbert: bgilbert 'Benjamin Gilbert' <bgilbert@backtick.net>
16:31:39 <dustymabe> well hello all you beautiful faces out there
16:31:40 <sumantro> .hello sumantro
16:31:41 <zodbot> sumantro: sumantro 'Sumantro Mukherjee' <sumantro@outlook.com>
16:31:42 <dustymabe> .hello2
16:31:44 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:31:46 <darkmuggle> .hello2
16:31:47 <lucab> .hello2
16:31:48 <bcotton> .hello2
16:31:50 <zodbot> darkmuggle: darkmuggle 'None' <me@darkmuggle.org>
16:31:51 <sumantro> .hello2 sumantrom
16:31:52 <zodbot> lucab: lucab 'Luca Bruno' <lucab@redhat.com>
16:31:55 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
16:31:58 <dustymabe> this might be a record
16:31:58 <zodbot> sumantro: sumantro 'Sumantro Mukherjee' <sumantro@outlook.com>
16:32:20 <kparal> (kparal coremodule and sumantro are here to discuss the upcoming test day)
16:32:30 <dustymabe> #chair cyberpear jlebon skunkerk kparal coremodule davdunc slowrie bgilbert sumantro darkmuggle lucab bcotton
16:32:30 <zodbot> Current chairs: bcotton bgilbert coremodule cyberpear darkmuggle davdunc dustymabe jlebon kparal lucab skunkerk slowrie sumantro
16:32:46 * dustymabe smiling
16:33:11 <dustymabe> i'll give a few more moments for people to join
16:33:50 <dustymabe> #topic Action items from last meeting
16:34:06 <dustymabe> I don't see any actions from laste meeting: https://meetbot-raw.fedoraproject.org/teams/fedora_coreos_meeting/fedora_coreos_meeting.2020-05-27-16.30.txt
16:34:07 <jdoss> .hello2
16:34:08 <zodbot> jdoss: jdoss 'Joe Doss' <joe@solidadmin.com>
16:34:11 <dustymabe> #chair jdoss
16:34:11 <zodbot> Current chairs: bcotton bgilbert coremodule cyberpear darkmuggle davdunc dustymabe jdoss jlebon kparal lucab skunkerk slowrie sumantro
16:34:24 <dustymabe> thanks lucab for running the meeting last week
16:34:45 <dustymabe> #topic meeting agenda
16:35:05 <dustymabe> it looks like we have some fedora qa representatives here today to discuss the pending test day - so we'll definitely add that to the agenda
16:35:11 <dustymabe> we also have the meeting tickets
16:35:31 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/labels/meeting
16:36:15 <dustymabe> any other topics we'd like to add to the agenda ?
16:36:35 <dustymabe> big topics preferrably - other things can wait for open floor
16:37:20 <cyberpear> rojig
16:37:43 * cyberpear can wait Open Floor
16:37:47 <dustymabe> cyberpear: +1
16:37:59 <dustymabe> #topic Fedora Test day for our `next` stream (Fedora 32)
16:38:04 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/491
16:38:17 <kparal> #link https://fedoraproject.org/wiki/Test_Day:Fedora_32_CoreOS_2020-06-08
16:38:18 <dustymabe> #info we have just moved our `testing` stream over to Fedora 32
16:38:28 <kparal> #link http://testdays.fedorainfracloud.org/events/84
16:38:54 <dustymabe> kparal: thanks! I see you have an open question for some of us in https://github.com/coreos/fedora-coreos-tracker/issues/491#issuecomment-638025251
16:39:15 <dustymabe> I have not had a chance to look at the test cases yet
16:39:33 <kparal> ok, has anyone else looked at them yet?
16:39:36 <dustymabe> but after these releases go out (should be done soon after this meeting) I'll definitely look at them
16:39:59 <kparal> please do review the test cases and don't be afraid to edit them on the spot
16:40:05 <kparal> those are your test cases after all :)
16:40:09 <dustymabe> kparal: i.e. edit directly in the wiki?
16:40:12 <kparal> sure!
16:40:29 <dustymabe> ok cool - anyone else want to take an action to review the test cases ?
16:40:35 <kparal> dustymabe: can you verify whether you see an Edit button on those test case pages?
16:40:46 <kparal> e.g. https://fedoraproject.org/wiki/User:Sumantrom/Draft/Testcase_CoreOS_virtual_install
16:40:52 <kparal> you need to be logged in
16:41:08 <jlebon> i'll take a look too
16:41:11 <kparal> I guess it might require CLA+1 group, which I assume most of you should have
16:41:33 <dustymabe> kparal: I see an edit button!
16:41:36 <kparal> great
16:41:46 <cyberpear> I see an edit button
16:42:10 <kparal> also, please don't be afraid to create new test cases if you want to cover more use cases. We tried to prepare some basics, but it's really up to you what exactly you want to see covered
16:42:30 <kparal> according to the audience, where you want to get UX feedback from users, etc
16:42:36 <dustymabe> kparal: we did just move our `testing` release over to f32, but testing against `next` should work too (same content for now)
16:42:46 <dustymabe> so we can just leave the test cases referring to `next` and it should be fine
16:42:52 <kparal> ok, sounds good
16:43:10 <cyberpear> Do Test Days usually look at the branched release, or current release?
16:43:15 <dustymabe> though if there are any upgrade tests we may want to start from testing.. i'll try to keep that in mind when looking at the tests
16:43:32 <dustymabe> cyberpear: usually test days are for the upcoming major release
16:43:37 <dustymabe> but we're a bit behind here
16:43:45 <kparal> the test day is on Jun 8th, so we have time to finalize the test cases until then. I'd like to move the testcases to permanent URLs (out of Sumantro's home) on Friday at the latest
16:43:58 <kparal> but we can still edit them even after that of course
16:44:18 <dustymabe> +1
16:44:24 <kparal> but if you tell us some of the test cases should be dumped, we can dump them without renaming them to the "proper" wiki names
16:44:28 <dustymabe> cyberpear: does that make sense?
16:44:33 <kparal> so that's the reason why they are still with temporary names
16:44:45 <cyberpear> yep, makes sense
16:45:21 <kparal> if you create new test cases, just update your github ticket or our pagure ticket and I'll add them to the testday results page (the last #link)
16:45:33 <dustymabe> #action dustymabe and jlebon (and anyone else who wants to) will review test cases linked from the various test day pages and try to fixup things that need fixing
16:45:51 <dustymabe> kparal: regarding communications around the test day - how do we want to handle that ?
16:46:13 <kparal> I instructed the visitors to join #fedora-coreos channel
16:46:25 <kparal> that's mentioned on the test day wiki page
16:46:35 <kparal> so everything would be discussed in there
16:46:36 <dustymabe> ahh yep that's good, but I was wondering about blog posts or fedmag article
16:46:53 <dustymabe> not required for you to do that, just wondering if there was something planned
16:46:56 <kparal> sumantro: that's a question for you :)
16:46:57 <coremodule> kparal, why aren’t we using the #fedora-test-day that we usually use?
16:47:52 <kparal> coremodule: usually a dedicated irc is not available, and this will help join the audience from people coming just for the test day and the regular users who are already connected or familiar with #fedora-coreos
16:47:54 <sumantro> fedmag blogpost to happen in an hr
16:48:01 <sumantro> and so is commblog
16:48:07 <sumantro> just finishing the draft
16:48:09 <kparal> also, dustymabe said earlier they'd prefer #fedora-coreos iirc
16:48:16 <dustymabe> kparal: coremodule: either way works for me
16:48:35 <sumantro> the announcement went out to @test @test-annouce already
16:48:38 <kparal> we'll set up a #topic on #fedora-test-day that will redirect people to #fedora-coreos
16:48:38 <lucab> we agreed during the last meeting that keeping it on #fedora-coreos was a sensible thing to do
16:48:47 <dustymabe> SGTM
16:49:04 <coremodule> wfm!
16:49:10 <kparal> sumantro: (please remember to set up that #topic if I forget, thanks) ^^
16:49:28 <sumantro> kparal, I will take care of it :)
16:49:51 <sumantro> dustymabe, here's the call for testers announcement : https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/thread/HL4BSOGIAH6AB5H7KW3IOKOB4MBE7V5N/
16:49:52 <dustymabe> thanks so much kparal and sumantro for continuing to follow up and help us organize this
16:49:59 <kparal> dustymabe: you can review sumantro's announcement draft before he sends it out, if you want, just talk to him
16:50:26 <kparal> also, please spread the announcement in your own channels, both internally in RH and in your FCOS or CL-related communities
16:50:36 <dustymabe> +1
16:50:37 <kparal> that's important, because we don't know how to reach the right audience, thanks
16:51:05 <jlebon> we can add it as a topic on #fedora-coreos maybe?
16:51:10 <dustymabe> #info FCOS test day announcement on the qa fedora list: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/thread/HL4BSOGIAH6AB5H7KW3IOKOB4MBE7V5N/
16:51:28 <dustymabe> i'll touch on possible other communications here soon
16:51:42 <sumantro> dustymabe, thanks +1
16:51:48 <dustymabe> #topic F32 rebase tracker for changes discussion
16:51:52 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/372
16:52:03 <dustymabe> ok this is our generic ticket for discussing the rebase to f32
16:52:30 <dustymabe> i think it's worth calling out known issues
16:52:46 <dustymabe> we did just switch `testing` to f32
16:53:22 <dustymabe> we have a reported known issue in https://github.com/coreos/fedora-coreos-tracker/issues/512
16:53:34 <lucab> dustymabe: I think it's worth having some kind of "fallout/f32" label on GH, mind if I tag them?
16:54:02 <dustymabe> #info known issue in f32 testing release with selinux labeling absolute symlinks after ignition run https://github.com/coreos/fedora-coreos-tracker/issues/512
16:54:05 <dustymabe> lucab: SGTM
16:54:50 <dustymabe> #info known kernel issue when testing our nodes on AWS https://github.com/coreos/fedora-coreos-tracker/issues/507
16:55:03 <dustymabe> #undo
16:55:03 <zodbot> Removing item from minutes: INFO by dustymabe at 16:54:50 : known kernel issue when testing our nodes on AWS https://github.com/coreos/fedora-coreos-tracker/issues/507
16:55:14 <dustymabe> #info known kernel issue in f32 testing when testing our nodes on AWS https://github.com/coreos/fedora-coreos-tracker/issues/507
16:56:02 <dustymabe> despite these two issues we have decided to go ahead and switch the `testing` stream to f32. The symlink selinux issue is easily worked around and the AWS kernel issue we think is harmless (happens on shutdown)
16:56:34 <dustymabe> I'm thinking we maybe should do some sort of coreos-status post that details a few things
16:56:44 <dustymabe> - we switched `testing` to f32 and it's coming to stable soon
16:56:54 <dustymabe> - highlight above mentioned known issues that we are investigating
16:57:01 <dustymabe> - draw attention to the test day
16:57:30 <jlebon> +1
16:57:35 <bgilbert> +1 because of point 2
16:57:58 <dustymabe> any NACKs ?
16:58:37 <dustymabe> #agreed we'll send out a coreos-status post with some relevant information about the rebase to f32 and possible issues people might be seeing
16:59:12 <dustymabe> bgilbert: actually I wonder if we also need to mention to people that they'll probably want to bump their `coreos-installer` versions they are using (if they aren't using the install media)
16:59:37 <bgilbert> dustymabe: yeah, because of the late key bump
16:59:42 <bgilbert> good thought
16:59:45 <dustymabe> +1, we won't have that problem in the future
16:59:56 <dustymabe> but this time it's good to call it out
17:00:05 <lucab> dustymabe: https://github.com/coreos/fedora-coreos-tracker/issues?q=is%3Aissue+label%3Afallout%2Ff32+
17:00:25 <dustymabe> bgilbert: jlebon: either of you want to send that coreos-status post. If not I'll do it later today
17:00:35 <bgilbert> feel free :-P
17:00:49 * dustymabe wonders if we should copy the fedora devel@ list as well
17:01:02 <jlebon> dustymabe: go ahead :)
17:01:24 <dustymabe> #action dustymabe to send coreos-status post with relevant information about the change to fedora 32
17:01:47 <dustymabe> #topic RFC: Merge coreos/ignition-dracut into coreos/ignition
17:01:53 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/511
17:02:07 <dustymabe> darkmuggle: want to set the stage here?
17:02:16 <darkmuggle> Sure
17:02:49 <darkmuggle> So for a while we have had Ignition and Ignition's Dracut support in two separate Github repositories
17:03:30 <darkmuggle> One of the things that has come up a few times is that there are features in Ignition that require Dracut support
17:03:48 <darkmuggle> A great example is the forth-coming support for complex devices (i.e. LUKS)
17:04:22 <darkmuggle> We have danced around the idea of merging the dracut code into the Ignition code base itself.
17:04:57 <darkmuggle> After it recently came up again, I am proposing that we merge the two code bases together into Ignition itself.
17:05:08 <cyberpear> would it make any sense to merge it into dracut instead?
17:05:12 <cyberpear> or is it very ignition-specific?
17:05:27 <darkmuggle> Its very Ignition specific.
17:05:40 <jlebon> the backstory here is that ignition-dracut was forked from CL's bootengine repo, which contained many more dracut things
17:06:01 <dustymabe> added a comment here: https://github.com/coreos/fedora-coreos-tracker/issues/511#issuecomment-638329716
17:06:07 <jlebon> we've mostly pruned everything away now, and we can move the few remaining things into fedora-coreos-config
17:06:25 <dustymabe> TL;DR this might make it slightly harder to pick up just changes in ignition-dracut files without pulling in all upstream changes in ignition itself
17:06:38 <dustymabe> but that's the only downside I really see
17:07:26 <darkmuggle> The upsides is that it makes introducing new features a bit easier, and should help with correlating changes in the dracut modules to the Ignition version.
17:07:26 <slowrie> dustymabe: I mean technically it would be the same where we could still just bump the ignition hash (though it's better to keep it tied to release tags)
17:07:50 <dustymabe> slowrie: right, I see bumping the ignition hash (and building from master) as a bit more risky
17:08:12 <dustymabe> whereas for ignition-dracut (separate repo) I didn't view it as quite as risky
17:08:43 <jlebon> another minor complication here is that ignition-dracut's spec2x is still used by RHCOS. though hopefully not for too much longer
17:08:56 <dustymabe> bgilbert: lucab: I'm interested in your opinions on this since you know more of the history all the way back to the bootengine days
17:09:05 <dustymabe> slowrie: as well
17:09:33 <bgilbert> jlebon: in principle we could merge ignition-dracut spec2x into ignition spec2x, but yeah, probably easier to wait
17:09:38 <slowrie> Not agreeing either way here but I would say that with the context of not wanting to include non-release tag'd changes I don't think it's feasible with the current ignition release process
17:09:54 <slowrie> So we'd need to scope in work to get that more automated
17:09:55 <bgilbert> slowrie: how so?
17:09:59 <slowrie> signing
17:10:11 <bgilbert> I don't follow
17:10:13 <dustymabe> slowrie: if we wanted to pick up changes we'd just add a patch to the rpm
17:10:19 <bgilbert> ^
17:10:34 <bgilbert> which is probably a more "honest" approach than bumping a sidecar repo anyway
17:10:40 <darkmuggle> ^
17:10:45 <slowrie> I guess that's fair
17:10:53 <bgilbert> dustymabe: at this point I'm +1 to merging
17:10:54 <bgilbert> one caveat
17:11:19 <bgilbert> the premise so far has been that ignition-dracut is "optional"
17:11:19 <lucab> (I don't have much input here. For afterburn we keep the dracut part in-repo but there isn't much variance across distros.)
17:11:31 <bgilbert> i.e. distros might just implement their own thing instead
17:11:47 <bgilbert> at this point, there's so much complexity in ignition-dracut that I don't think that's feasible
17:11:59 <dustymabe> #proposed Merging ignition-dracut into ignition seems to have clear advantages and the disadvantages seem to be minor or easily worked around.
17:12:08 <slowrie> bgilbert: even if we include it in repo isn't it still optional in that they still have to package it and can choose to include the binary and their own bits?
17:12:22 <dustymabe> bgilbert: right, i think distros can still just ignore that part of the source code if they'd like
17:12:26 <darkmuggle> I second slowrie's comment.
17:12:31 <bgilbert> well sure, but we'll feel free to have complex dependencies between them
17:12:35 <bgilbert> free-r
17:12:36 <jlebon> dustymabe: that proposal is more of an observation than a plan of action :)
17:12:46 <bgilbert> so anyway, if we merge, we should be more careful not to have *COS-specific stuff in the dracut modules
17:12:50 <bgilbert> which I'm +1 to anyway
17:12:53 <dustymabe> but we should still work with Suse (other known users) to try to do this in a non-painful way for them (gives us some insight into making it easier for other distros as well)
17:12:58 <jlebon> bgilbert: yup, agreed
17:13:21 <slowrie> We already have the current separation with some ignition related units being in fedora-coreos-config
17:13:22 <lucab> bgilbert: is *COS-specific stuff basically ostree bits?
17:13:35 <darkmuggle> I would make the proposal: Merge Ignition specific Dracut modules into Ignition and *COS modules into Fedora CoreOS Config.
17:13:37 <dustymabe> #proposed Merging ignition-dracut into ignition seems to have clear advantages and the disadvantages seem to be minor or easily worked around. We'll merge them together unless clear blockers come up when attempting the transition.
17:13:44 <lucab> bgilbert: or is there more you see as a concern?
17:14:02 <slowrie> Can we add a note that it'd be nice to delay that work a bit
17:14:05 <bgilbert> lucab: anything tied to *COS-specific behavior that happens to touch Ignition
17:14:10 <slowrie> I'd like to not do more rebases :)
17:14:11 <jlebon> lucab: see https://github.com/coreos/fedora-coreos-tracker/issues/511#issuecomment-637629796
17:14:19 <bgilbert> we've had some leakage in the past
17:14:32 <dustymabe> #proposed Merging ignition-dracut into ignition seems to have clear advantages and the disadvantages seem to be minor or easily worked around. We'll merge them together in the future (when it's safest to do so) unless clear blockers come up when attempting the transition.
17:14:52 <bgilbert> dustymabe: +1
17:14:52 <dustymabe> slowrie: better ^^ ?
17:14:52 <lucab> jlebon: great list, thanks
17:14:53 <jlebon> +1
17:15:08 <darkmuggle> +1
17:15:26 <dustymabe> any opposed?
17:15:27 <slowrie> yeah wfm, I'm hoping to get the PRs up for the LUKS stuff soon-ish (this week or next) and just don't want to have to deal with merging more stuff & rebasing again
17:15:28 <slowrie> +1
17:16:06 <dustymabe> i'm thinking we at least get this f32 transition out of the way and maybe switching RHCOS over to the new ignition version/spec and then do it, but I'm not tied to that
17:16:33 <dustymabe> #agreed Merging ignition-dracut into ignition seems to have clear advantages and the disadvantages seem to be minor or easily worked around. We'll merge them together in the future (when it's safest to do so) unless clear blockers come up when attempting the transition.
17:16:59 <dustymabe> thanks for bringing that up darkmuggle - and for everyone having a fruitful discussion
17:17:00 <jlebon> i think it's fine to not block on RHCOS moving over. we could just delete the master branch and make the default branch spec2x to make it obvious
17:17:07 <cyberpear> getting RHCOS over to current ignition makes life a lot easier and gives much more freedom
17:17:20 <dustymabe> I'd prefer not to delete any code in repos :)
17:17:32 <cyberpear> yeah, never delete code
17:17:53 <dustymabe> #topic network interface name differs between Fedora CoreOS and RedHat CoreOS
17:17:57 <jlebon> fair -- switch the default branch then :)
17:18:00 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/484
17:18:31 <cyberpear> worst case, "GitHub Archive" it... I hate even when projects delete the all code in the repo in a final "we're done" commit, leaving the history if you dig for it
17:18:33 <jlebon> (though git history is another unfortunate casualty of this)
17:18:38 <dustymabe> looks like this was discussed last week - do we want to formalize our plans ?
17:18:55 <slowrie> +1 to archiving it
17:19:01 <cyberpear> you can include the history during the move with git subtree
17:19:16 <jlebon> sorry, let's move on to $topic
17:19:50 <dustymabe> i had a question in https://github.com/coreos/fedora-coreos-tracker/issues/484#issuecomment-637008004
17:20:16 <jlebon> dustymabe: that's correct
17:20:27 <cyberpear> an obvious bug in #topic with easy fix, but handling existing systems will be the tricky part
17:20:37 <jlebon> i think it's likely other "migration" things like this will come up in the future
17:20:57 <lucab> I think I was still trying to put systemd-naming-scheme pinning in the same ticket last week, but I think it's unreasonable, so jlebon's plan should be good
17:22:28 <dustymabe> #proposed For this issue we'd like to correct the behavior but realize it would be a disruption for existing nodes that upgrade. We propose to add a barrier node in our update graph that will keep behavior for updating nodes the same, while fixing the bug and causing new behavior for newly installed nodes.
17:23:10 <jlebon> lucab: when we move over, should we still make sure we pin to some scheme so it doesn't change under us in the future?
17:23:31 <lucab> jlebon: longer term I think so
17:23:51 <lucab> jlebon: but I don't think it's as urgent as moving out of eth*
17:24:01 <jlebon> ack
17:24:07 <jlebon> +1 to proposal
17:24:20 <cyberpear> eth* makes sense for cloud, not hardware
17:24:46 <cyberpear> but I guess users can request that at install time
17:24:57 <dustymabe> any opposed to the current proposal?
17:25:06 <dustymabe> please ack/nack
17:25:15 <bgilbert> +1
17:25:24 <lucab> ack
17:25:59 <cyberpear> ack
17:26:08 <dustymabe> #agreed For this issue we'd like to correct the behavior but realize it would be a disruption for existing nodes that upgrade. We propose to add a barrier node in our update graph that will keep behavior for updating nodes the same, while fixing the bug and causing new behavior for newly installed nodes.
17:26:45 <dustymabe> I assume for $timing on when to make this change we should either let the f32 changes propagate out safely and then revisit on when to make this change
17:26:56 <dustymabe> OR do it at the same time as the transition to f32 for stable
17:27:10 <dustymabe> i think probably the former for now since we've got a lot going on already
17:28:01 <jlebon> sounds reasonable to me
17:28:21 <lucab> ballpark ETA was "before OKD goes GA"
17:28:26 <dustymabe> ok it looks like we're running out of time so i'll skip the last meeting ticket
17:28:29 <dustymabe> #topic open floor
17:28:33 <dustymabe> cyberpear: I think you had a topic
17:28:35 <dustymabe> anyone else?
17:28:37 <bcotton> o/
17:28:39 <dustymabe> go for it
17:29:11 * cyberpear waits for bcotton
17:29:19 <bcotton> thanks cyberpear
17:29:35 * lucab waves back to bcotton
17:30:07 <bcotton> so when we set up the BZ component for FCOS, we talked about cc'ing the FAS group on bugs. it appears that you *can* in fact email FAS groups, so is that something we want to pursue or let it sit for now?
17:30:34 <dustymabe> SGTM - i have to check what fas groups even exist for us
17:31:00 * cyberpear should join the FCOS fas group
17:31:07 <dustymabe> in general we should try to make it so that it doesn't send to $everyone, (a few people should be enough)
17:31:15 <dustymabe> but a single person is a single point of failure too
17:31:31 <dustymabe> for some context - the BZ component is just there to redirect people to our issue tracker
17:31:45 <bcotton> the other option would be to have people watch that component themselves
17:31:48 <dustymabe> but some people will probably still open some issues and we don't want that to go into /dev/null
17:32:16 <dustymabe> bcotton: that might be ok too
17:32:28 <dustymabe> I'd have to remind myself how to watch a component in bugzilla
17:33:00 <dustymabe> but if we could get a few of us to volunteer (the job is basically to try to redirect people to the issue tracker, or point them at issues that already exist for what they reported) then that would work
17:33:04 <lucab> I seem to be in a "coreos" FAS group
17:33:12 <bcotton> https://bugzilla.redhat.com/userprefs.cgi?tab=component_watch
17:33:38 <dustymabe> and what's the component again?
17:33:51 <bcotton> gosh, i have to know everything :p
17:33:55 <dustymabe> :)
17:34:12 <dustymabe> it's why we love you
17:34:40 <jlebon> is it possible to have a custom template that points to the tracker?
17:34:50 <dustymabe> anyone else want to volunteer to watch the component and do the described $job from above ?
17:34:56 <dustymabe> jlebon: yeah I think he already set that up for us
17:34:58 * jlebon raises hand
17:35:04 <jlebon> ahh cool, very nice
17:35:20 <bcotton> Product: Fedora, Component: fedora-coreos
17:35:51 <dustymabe> ok I watched that component
17:35:54 <jlebon> added ✔️
17:36:13 <jlebon> pheww, no bugs in there yet
17:36:16 <dustymabe> sounds like cyberpear wanted to too 👀
17:36:41 <dustymabe> ok any other topics for open floor ?
17:36:51 <cyberpear> we're kind of at the end of time
17:37:00 <cyberpear> but I wanted to talk about rojoig briefly
17:37:13 <cyberpear> is this on the near or medium-term roadmap?
17:37:27 <cyberpear> yum mirroring infrastructure is widespread, but most tools don't know about ostree
17:37:37 <cyberpear> and it seems that pulp3 doesn't support ostree either
17:37:47 <dustymabe> ahh like rpm-ostree rojig ?
17:38:12 <cyberpear> yes, rojig "rpm-ostree jigsaw", would allow riding on the back of all the existing yum mirroring solutions
17:38:25 <bgilbert> previous discussion at https://github.com/coreos/fedora-coreos-tracker/issues/23
17:38:28 <cyberpear> for offline and "disconnected" use cases where the network isn't on the internet
17:38:39 <lucab> I share this sentiment on "how should I mirror FCOS ostree repo"
17:38:52 <cyberpear> OpenShift solves it by shoving the ostree into a container, but that's very heavy weight w/ lots of duplication
17:39:31 <dustymabe> lucab: but it's pretty easy to mirror with `ostree pull` for individual use cases
17:39:39 <lucab> cough it's a quay.io stress-test plan cough
17:39:43 <jlebon> on that topic, see https://blogs.gnome.org/alexl/2020/05/13/putting-container-updates-on-a-diet/
17:40:01 <jlebon> there's working code at https://github.com/flatpak/flatpak/pull/3606
17:40:13 <cyberpear> yes, that's good work, but there's still not a good container "registry" mirroring solution, only repo-by-repo
17:41:33 <bgilbert> cyberpear: so to answer your literal question, it is not currently on the roadmap AFAIK
17:41:37 <dustymabe> cyberpear: I don't really have a good answer for you. It would take a decent amount of work to get from where we are to delivering things via rpm-ostree rojig.
17:41:46 <cyberpear> I think rpm-ostree rojig is the "best thing since sliced bread" in terms of leveraging existing infrastructure, but shrinking container deltas is also very helpful
17:42:08 <cyberpear> Thanks... good enough for today. I know we're over time.
17:42:09 <lucab> dustymabe: I'm not saying it isn't, but everything I've seen so far are single-use artisanal recipes
17:42:29 <dustymabe> lucab: so you want an enterprise mirroring tool to support it basically?
17:42:36 <cyberpear> if it were an/the native way of doing it, users wouldn't be creating the rojig, only consuming it
17:43:09 <jlebon> hmm, AFAIK pulp does support ostree
17:43:17 <jlebon> (re. something you said earlier)
17:43:22 <cyberpear> pulp2 does, pulp3 does not, afaik
17:43:36 <cyberpear> pulp2 is maintenance mode
17:43:38 <jlebon> ahh i see. interesting
17:43:38 <dustymabe> yeah they may have ripped it out for some reason
17:43:41 <lucab> dustymabe: maybe, or some turn-key container? I don't exactly know, but I was having a similar sentiment that it is an under-appreciated areaa
17:44:05 <cyberpear> probably ripped it out since RH doesn't need it since their only use of RHCOS is OCP and they ship containers w/ ostree there
17:44:11 <dustymabe> cyberpear: it might be worth a ticket and more discussion
17:44:23 <cyberpear> not so much "ripped it out" as "didn't build it" since pulp3 is very plugin-focused
17:44:47 <cyberpear> probably no pulp_ostree plugin for 3, but I didn't look too closely in the past month
17:45:03 <cyberpear> I'll try to open a ticket
17:45:06 <dustymabe> ok i'm going to close out the meeting soon since we're 15 minutes over
17:45:12 <cyberpear> thanks, all!
17:45:24 <jlebon> thanks!
17:45:36 <dustymabe> #endmeeting