16:00:18 <davide> #startmeeting Hyperscale SIG
16:00:18 <centguard> Meeting started Wed Jul  6 16:00:18 2022 UTC.  The chair is davide. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:18 <centguard> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:00:18 <centguard> The meeting name has been set to 'hyperscale_sig'
16:00:32 <davide> #chair dcavalca jvreeland
16:00:32 <centguard> Current chairs: davide dcavalca jvreeland
16:00:42 <davide> morning everyone
16:00:53 * kcwells waves
16:03:51 <davide> alright, let's get started
16:03:53 * Eighth_Doctor waves
16:04:03 <davide> #topic Followups
16:04:03 <Eighth_Doctor> hey all
16:04:17 <davide> I have two followups from the last time
16:04:19 <chantra> hello world
16:04:50 <davide> for the August Dojo/Devconf thing in Boston, we're trying to get meeting space for Aug 16 to do a SIG meetup there
16:05:09 <davide> still waiting to hear back from Shaun on specifics, but I'm reasonably confident we'll sort something out there
16:05:23 <davide> if you haven't booked travel/hotels yet, now would probably a good time to do so
16:05:46 <davide> use https://www.marriott.com/event-reservations/reservation-link.mi?id=1642719883011&key=GRP&app=resvlink if you want to stay at the hotel next to the venue
16:05:59 <DaanDeMeyer[m]> Hi everyone
16:06:10 <anitazha> nice. was just about to ask that :D
16:06:43 <davide> I've also submitted a talk for our usual SIG update to that Dojo
16:06:54 <davide> CFP is still open, so if you have stuff to talk about feel free to submit something
16:07:39 <chantra> davide, will there be VC during the SIG meetup?
16:07:42 <davide> next up, chair election
16:08:05 <davide> chantra: there can be if people want to
16:08:30 <davide> it'll likely be a bit of a crappy experience because of the nature of these kind of things, but we can certainly try at least
16:08:44 <davide> I know for Dojo proper Shaun was planning to have at least one remote presentation
16:08:57 <chantra> I will very likely not be able to come in person, if it is only me, prob not worth it, but maybe we can try to test water and see if it would be useful?
16:09:43 <davide> yeah, I'm down for rigging up a zoom bridge or something in any case
16:10:32 <kcwells> As of now, I don't think any of us Intel folk have travel budget to go in person, so I'd be interested in a VC
16:11:29 <davide> yeah we'll figure something out, definitely want to make this as inclusive as possible if we can
16:12:13 <davide> also on the subject of conferences, myself Anita and Neal will be at SCALE in LA at the end of July
16:13:00 <davide> no specific events planned there afaik, but I'll have a talk around CentOS Stream and there's going to be a booth of some kind
16:13:44 <anitazha> i'll be doing a debugging story talk about systemd-journald. and joint talk with Alvaro about using systemd in general
16:14:32 <kcwells> Sounds cool!
16:15:14 <davide> let's make sure to get this stuff in the SIG report so people know it's happening
16:15:38 <davide> I meant to finish it yesterday but got sidetracked by work, hopefully I can wrap it up today
16:15:46 <davide> https://hackmd.io/kgwf1KVnRHO1ezpztWaUGw is the current draft
16:16:14 <DaanDeMeyer[m]> systemd should be complete, not that much happened
16:17:04 <DaanDeMeyer[m]> well the daily CD was a struggle but nobody wants to read about openshift I guess
16:17:19 <davide> oh that'd be worth mentioning actually, if only to remind folks that openshift exists
16:18:09 <DaanDeMeyer[m]> Maybe it's better if everyone forgets it exists 🤣
16:18:13 <DaanDeMeyer[m]> But I can expand a bit on it
16:18:39 <davide> thanks
16:18:51 <davide> alright, the other followup I had was about the chair elections
16:19:09 <davide> as y'all know jvreeland had decided to step down as co-chair and we had to fill his seat
16:19:32 <davide> we had a single nomination from Neal in https://pagure.io/centos-sig-hyperscale/sig/issue/120 so there was no need to hold an actual election
16:20:14 <davide> #info Conan_Kudo elected as SIG co-chair replacing jvreeland
16:20:35 <davide> I'll add a blurb on this in the SIG report as well and signal boost it when I share it on the mailing list
16:20:38 <Eighth_Doctor> 👌
16:20:54 <davide> I've also started putting together a quick governance writeup for the next time we have to do this
16:21:05 <davide> I'll put that as a PR against the SIG docs later so everyone can review it
16:21:05 <anitazha> congrats Conan Kudo !
16:21:05 * chantra opening 🍾 to celebrate.
16:21:53 <kcwells> 🥳
16:22:04 <DaanDeMeyer[m]> Congrats!
16:22:35 <oidoming> congrats :D
16:23:10 <davide> anything else for followups?
16:24:54 <davide> alright, let's move to
16:24:56 <davide> #topic Announcements
16:25:32 <davide> on my end, I'm going to do a hotfix build of the el8 kernel package so we can fix perf, as it's currently not installable
16:26:14 <davide> I say hotfix because despite my best efforts I haven't managed to generate a buildable package for el8 from our linux repo, so I'm just going to bump the release in the actual spec and patch the fix it for now
16:26:29 <davide> once we've sorted out the branch we can cut another "proper" release
16:27:02 <davide> jvreeland: if you happen to still have the branch that was used to build the last el8 kernel, that would definitely be helpful here
16:28:53 <davide> the only other announcement I have is that we can now make PRs against repos on git.centos.org and we should be able to actually merge them
16:29:16 <davide> this is still a bit of hack and repos need to be manually added to an ACL by the infra team for the time being
16:29:19 <chantra> @davide, want me to bring up the RPM update race condition thingy here? or later in misc?
16:29:31 <davide> so if you see a specific repo where this isn't working, file a ticket on centos-infra and they'll sort it out
16:29:41 <davide> chantra: here is totally fine, go for it
16:30:04 <chantra> ok, I will type the blurb :)
16:33:08 <chantra> I think this is a SIG at large issue, but worth raising here for awareness. It can be tricky to ensure that our packages are not reverted back to upstream CentOS. Even with @oidoming work on https://pagure.io/centos-sig-hyperscale/package-updates/issues , there is a time window when, for packages that we rebuild after merging changes to CentOS's one, we have the upstream package out and the hyperscale still has a lower version, so essentally
16:33:08 <chantra> reverting back to upstream.This can be pretty bad when hyperscale package is not backward compatible.
16:34:00 <chantra> there is definitely some solutions to shrink that time window, like having a bot to auto-generate the spec and create a staging package that a human may tag as release later.
16:34:42 <chantra> there is probably ways to handle this more gracefully, like vendor pinning or what not, but it would also probably be useful to document that somewhere.
16:35:20 <davide> so I think sticky vendors would probably mitigate the bulk of this in practice
16:35:35 <davide> but it needs to be enabled client side, so we can't necessarily rely on it in all environments
16:35:44 <davide> e.g. we do turn it on in our spin, but it's not on in stock centos
16:35:57 <chantra> yeah. probably, but it may be worth documenting so people don't have to go through the same pain and discovery process
16:36:10 <davide> having some automation around updates would be useful regardless
16:36:24 <davide> as a lot of those are just toil anyway, and anything we can do to reduce that is a good thing
16:36:54 <chantra> yes agreed, but even with automation, the time window will still be there, albeit smaller.
16:37:29 <chantra> so, there is probably some best practices to document on how to manage SIG packages from client side.
16:38:10 <chantra> I have no idea of the vendoring pinning is working, so talking off my hat here. IIRC, @salimma had brought this up when we debugged this.
16:38:41 <chantra> how about we have issues to tackle this on different front: 1) documentation 2) automation improvements
16:38:44 <davide> I suspect down the road we should make the case for sticky vendors to just be the default everywhere, and ensure SIGs all have their builds done with a dedicated vendor in CBS
16:39:00 <davide> but I agree, starting with some documentation here is a good idea
16:39:23 <davide> we can start putting together something specific for Hyperscale, and then bring it to the list for wider awareness for other SIGs
16:39:35 <chantra> yop, SGTM.
16:40:53 <davide> anything else for announcements?
16:42:53 <davide> next up
16:42:53 <davide> #topic Tickets
16:43:49 <davide> we already covered the election stuff, I'll clean those up after this
16:45:05 <davide> don't think we have any significant updates here this week?
16:46:42 <davide> #topic Membership
16:46:50 <davide> nothing here either I think
16:47:15 <davide> #topic Misc
16:47:26 <davide> anything else folks wanna talk about?
16:47:39 <oidoming> hey, I have this openshift issue with uids, I mentioned in the PR for containers-releng
16:47:54 <oidoming> openshift runs in a random uid like 1000650000, so the user you define in the containerfile is not used by openshift when running the container and buildah have conflict with these uids
16:48:13 <davide> ah yes, I saw that but didn't get a chance to try yet
16:48:26 <davide> we should have the same permissions though, so this is probably something that'll require infra help
16:48:38 <davide> I'll double check later and file a ticket on centos-infra if needed
16:48:56 <oidoming> okay, thanks
16:49:58 <chantra> on the misc front, I have a Q for @oidoming . We had a bunch of follow-ups in https://pagure.io/centos-sig-hyperscale/package-updates/pull-request/1 . Are they captured in one of the centos-sig-hyperscale repo? If not should we before we forget about them? Also, what would be the best repo to file issue in? I am afraid filing in https://pagure.io/centos-sig-hyperscale/package-updates may get lost amongst package update issues (albeit, this is
16:49:59 <chantra> not currently an issue).
16:51:11 <chantra> last time I used https://pagure.io/centos-sig-hyperscale/sig/issue/114 to file a feature request type of issue. Should we just use this repo?
16:51:29 <davide> yeah I think that's fine
16:51:40 <davide> we can make a tag for this too if that's easier
16:52:11 <chantra> @davide you are refering to using sig repo?
16:52:21 <davide> yeah
16:52:32 <oidoming> sounds good
16:53:25 <chantra> @oidoming, mind filling issues for the follow-ups? I don't remember which ones were addressed and which one were not and you are probably in the best position to know.
16:53:46 <oidoming> sure, I will create the issues
16:55:02 <davide> anything else for the last few minutes?
16:56:43 <chantra> ok, I created "package-updater" tag in sig repo https://pagure.io/centos-sig-hyperscale/sig/issues?tags=package-updater
16:57:19 <chantra> choose package-updater vs package-updates as I was afraid the latter would not clearly identify the tool vs generic package-updates
16:57:39 <davide> works for me
16:58:30 <chantra> if someone has ooinions, it can be edited :D
16:59:50 <davide> that's all for this week, thanks everyone for coming
16:59:53 <davide> #endmeeting