16:00:26 <dcavalca> #startmeeting Hyperscale SIG
16:00:26 <centbot> Meeting started Wed Jun  9 16:00:26 2021 UTC.  The chair is dcavalca. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:26 <centbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:00:32 <dcavalca> morning folks
16:00:33 <jvreeland> good morning
16:00:40 <dcavalca> #chair dcavalca jvreeland
16:00:40 <centbot> Current chairs: dcavalca jvreeland
16:01:00 <Eighth_Doctor> hey
16:01:10 <anitazha> morning
16:02:03 <dcavalca> let's get started
16:02:09 <dcavalca> #topic Followups
16:02:18 <dcavalca> LISA went well
16:02:31 <dcavalca> lots of discussion throughout my talk, and later on in Slack
16:02:47 <dcavalca> video isn't out yet but it should show up on youtube eventually
16:03:18 <dcavalca> jvreeland: did you send a cfp for devconf.us?
16:03:46 <jvreeland> @dcavalca not yet but the submission deadline was moved to the end of the month.
16:04:05 <michel> .hello salimma
16:04:10 <michel> I keep forgetting that does not exist
16:04:26 <dcavalca> jvreeland: alright, lemme put an action for this so we don't forget
16:04:40 <dcavalca> #action jvreeland submit cfp to devconf.us
16:04:56 <dcavalca> anybody else has followups?
16:05:36 <dcavalca> alright, let's move to
16:05:40 <dcavalca> #topic Announcements
16:06:08 <dcavalca> on my end, the LLVM 12 packages should be in decent shape, and we'll be deploying them on our infra soon
16:06:15 <dcavalca> I also pushed a few more updates for kpatch
16:06:27 <Eighth_Doctor> nice
16:06:43 <dcavalca> not much progress on the container image, I need to find some time to figure out how to get buildah running inside openshift
16:06:54 <dcavalca> so we can have automated builds for it
16:07:23 <Eighth_Doctor> that should not be too much of an issue, if you're having problems, you should ask in the openshift-users channel on k8s slack
16:07:58 <dcavalca> thanks Eighth_Doctor
16:08:12 <dcavalca> I'll probably try and tackle that next week
16:08:19 <dcavalca> anybody else has announcements?
16:09:10 <dcavalca> oh, I forgot, not really hyperscale related, but we've started mirroring composes.centos.org at http://mirror.facebook.net/centos-composes/8/
16:09:29 <dcavalca> as we needed that internally; might come in handy if you need a stable point reference for Stream to e.g. give to a vendor
16:09:32 <Eighth_Doctor> I have a couple
16:10:09 <Eighth_Doctor> I've made progress on the Anaconda tree and have a patch set prepared: https://pagure.io/centos-sig-hyperscale/anaconda/commits/c8s-hs-v33.16.5.2
16:10:26 <Eighth_Doctor> I'm waiting on the new version of Anaconda to land in CentOS git before finalizing it and building it
16:12:09 <dcavalca> sweet
16:12:36 <Eighth_Doctor> the other thing is that I've prepared branding for our Hyperscale spin
16:12:55 <Eighth_Doctor> and built it in the -spin repo: https://cbs.centos.org/koji/buildinfo?buildID=32942
16:15:09 <michel> nice!
16:15:59 <dcavalca> Eighth_Doctor: so I think once we have anaconda and the kernel we should be good to go here
16:16:03 <dcavalca> at least for a first cut
16:16:29 <Eighth_Doctor> yeah
16:16:56 <Eighth_Doctor> we'll probably want to turn on sticky vendors in DNF in hyperscale spin though
16:17:10 <Eighth_Doctor> otherwise package swapping could happen and that would suck
16:17:21 <dcavalca> what's sticky vendors?
16:18:02 <michel> setting our repo to be a higher priority?
16:19:16 <Eighth_Doctor> sticky vendors are when DNF will use the "Vendor" tag to track sources and lock on updates
16:19:49 <michel> huh, didn't know we can specifically use the vendor tag!
16:19:57 <Eighth_Doctor> e.g. Vendor: CentOS Project vs Vendor: CentOS Hyperscale SIG
16:20:05 <Eighth_Doctor> it was added to DNF in the RHEL 8.4 cycle
16:20:28 <dcavalca> til
16:20:29 <Eighth_Doctor> you can turn on sticky vendors by setting "allow_vendor_change=False" in /etc/dnf/dnf.conf
16:20:33 <dcavalca> yeah, this seems a good idea
16:20:36 <michel> should we add a minimum version requirement on centos-stream-release then?
16:20:57 <Eighth_Doctor> that won't work very well, so I would avoid it
16:21:04 <michel> ah
16:21:13 <michel> yeah, so that setting just won't be that useful if you're on an older centos
16:21:26 <michel> DNF let you add config files, right, so we don't have to edit dnf.conf?
16:21:34 <Eighth_Doctor> don't think so
16:21:43 <Eighth_Doctor> there was some effort to add that, but it was not finished
16:22:07 <Eighth_Doctor> there's skeleton support for a /etc/dnf/conf.d folder, but nothing plumbed through
16:22:08 <michel> hmm, yeah it does not
16:22:30 <michel> I can probably bring that up to the delayed community meeting (now this Friday). together with proposing repo overrides
16:22:52 <Eighth_Doctor> sounds good
16:23:55 <Eighth_Doctor> btw, bug report about sticky vendors: https://bugzilla.redhat.com/show_bug.cgi?id=1788371
16:24:22 <michel> dcavalca: jvreeland want to put that in info for the minutes?
16:25:01 <dcavalca> #info branding for our Hyperscale spin: https://cbs.centos.org/koji/buildinfo?buildID=32942
16:25:13 <jvreeland> #info bug report about sticky vendors: https://bugzilla.redhat.com/show_bug.cgi?id=1788371
16:26:16 <Eighth_Doctor> don't forget the anaconda stuff :)
16:26:37 <dcavalca> #info Hyperscale anaconda tree: https://pagure.io/centos-sig-hyperscale/anaconda/commits/c8s-hs-v33.16.5.2
16:26:43 <dcavalca> good catch :)
16:26:46 <dcavalca> anything else here?
16:27:56 <jvreeland> if not, moving back to the needs for the spin. Are we still planning to wait for signing? The last I read about it did not seem optimistic, at least with respect to a timeline.
16:28:07 <jvreeland> *wait for signing for the kernel
16:28:19 <Eighth_Doctor> we'll probably never have autosigning for the kernel
16:28:31 <dcavalca> jvreeland: we mostly only need signing for secure boot
16:28:47 <dcavalca> so I think it's probably ok to release without it, at least initially, but we will need a solution of some kind here
16:28:56 <michel> I think we should show use cases for an alternate kernel, rather than waiting for signing
16:29:10 <Eighth_Doctor> we can do stuff without signing initially
16:29:34 <Eighth_Doctor> but we'll need to patch some things to explicitly not do secure-boot type things
16:30:27 <Eighth_Doctor> we will also need to ask about a way to run image build tasks in CBS Koji
16:30:42 <Eighth_Doctor> if we can't do that, we'll do it the manual crappy way, but it'd be nice if we didn't have to
16:30:46 <dcavalca> Eighth_Doctor: can you file an infra ticket for that?
16:30:53 <dcavalca> better get the conversation started sooner than later
16:30:58 <Eighth_Doctor> yeah, will do
16:31:09 <dcavalca> #action Eighth_Doctor file infra ticket for image build tasks on CBS
16:31:43 <dcavalca> k, I think we can move to
16:31:46 <dcavalca> #topic Tickets
16:32:05 <dcavalca> I don't think there's any update for #47 (EPEL for our build tags)
16:32:35 <dcavalca> jvreeland: wanna update on the kernel stuff for #7?
16:36:18 <jvreeland> not much to update. There's a build able 5.12 kernel on our sig branch in rpms/kernel. There's also a branch from kernel-ark in our linux repo on pagure that I generated the current configs from for 5.12. Happy to build it and tag it experimental. It'd be nice to figure out what we want our development workflow/update cadence to be and for people to go over the configs to make sure they're acceptable.
16:38:14 <jvreeland> I've yet to encounter issues using the kernel on hosts/vms with secureboot disabled with the hyperscale repos enabled so I'm not sure what needs to be done to prevent those issues popping up if we did release a kernel.
16:39:30 <dcavalca> for experimental, it's probably ok to tag as-is
16:39:43 <dcavalca> for an actual release, I think the failure mode with secure boot enabled is that it just won't boot?
16:40:03 <jvreeland> Yeah, normally it just reboots and tries again from what i've seen
16:40:37 <jvreeland> not sure if that varies by firmware vendor though
16:41:18 <michel> any reason 5.12 is picked, rather than say an 'LTS'?
16:41:33 <Eighth_Doctor> that's what dcavalca said to use, afaik
16:41:58 <dcavalca> michel: yeah, that was a combination of aligning with what FB is using internally, and staying close to what'll end up in RHEL9
16:41:59 <Eighth_Doctor> we should try to see if we can work with the rhel kernel team, longterm
16:42:07 <dcavalca> agreed
16:42:11 <michel> ahh
16:42:37 <michel> there's some talk about getting the EL+1 kernel for us to use in EL, right?
16:42:45 <Eighth_Doctor> we've got a conversation going on to see how that should work out, but we don't have anything concrete yet
16:43:15 <Eighth_Doctor> right now the focus is on upstream enablement
16:43:32 <Eighth_Doctor> once the branch point from upstream and RHEL occurs, then we will refocus on their tree
16:46:33 <Eighth_Doctor> from there, we'll work on cherry-picking improvements from upstream into the rhel tree
16:46:50 <Eighth_Doctor> to support our needs
16:47:35 <Eighth_Doctor> but the details of that process are TBD
16:49:28 <dcavalca> yeah I think we'll need to flesh out and formalize the process more as we get closer
16:49:32 <dcavalca> but for now this is probably fine
16:49:52 <dcavalca> jvreeland: I'd say lets start by tagging the kernel in experimental so folks can begin testing and playing with it
16:49:57 <dcavalca> and we can take it from there
16:50:02 <dcavalca> sounds good?
16:50:12 <Eighth_Doctor> it's built with a Fedora config, right?
16:50:16 <jvreeland> #action tag current kernel for experimental
16:50:54 <jvreeland> Eighth_Doctor: yeah, i did also remove some joystick controllers and such when looking at the ark-kernel as well as ensure btrfs is there.
16:51:08 <Eighth_Doctor> excellent
16:51:19 <Eighth_Doctor> well, I guess no Steam Machines based on Hyperscale :P
16:51:36 <Eighth_Doctor> (I did seriously think of that idea 😛)
16:51:59 <dcavalca> know anybody at valve? that could be a fun conversation
16:52:23 <Eighth_Doctor> maaaybe
16:52:30 <Eighth_Doctor> I also need to reach out to the XCP-ng folks too
16:52:35 <michel> better than whatever fork of Debian they are using right?
16:52:42 <Eighth_Doctor> I would think so
16:52:54 <michel> but yeah, if they want to add Nvidia support out of the box, 5.12 is not a good idea right now
16:54:59 <michel> apropos of nothing, with 6 mins left... is there anything we want to bring up in the Stream office hour right after this?
16:55:25 <Eighth_Doctor> probably the signing stuff
16:55:49 <Eighth_Doctor> Michel Alexandre Salim: SteamOS already ships a custom non-LTS kernel afaik
16:56:02 <dcavalca> yeah, we should follow up on the signing stuff again
16:56:07 <michel> would love to pick their kernel people's brains
16:56:12 <dcavalca> and on EPEL for CBS builds
16:56:17 <Eighth_Doctor> yep
16:56:45 <dcavalca> #topic Membership
16:56:53 <dcavalca> I don't think we have anything here this time
16:56:59 <dcavalca> #topic Misc
16:57:00 <michel> yeah... some RH folks make noises about supporting people doing kmods etc. but... still have no answer for how to actually sign them
16:57:25 <dcavalca> michel: there is a proposal out for a centos kmods SIG fyi
16:57:45 <michel> dcavalca: saw that discussion! when is it getting voted on by the board?
16:58:16 <dcavalca> michel: there's a board meeting today, but I don't know if it made the agenda
16:59:59 <dcavalca> alright, I think our time is up
17:00:03 <dcavalca> thanks everyone!
17:00:09 <dcavalca> #endmeeting