16:32:37 <jlebon> #startmeeting fedora_coreos_meeting
16:32:37 <zodbot> Meeting started Wed Feb  8 16:32:37 2023 UTC.
16:32:37 <zodbot> This meeting is logged and archived in a public location.
16:32:37 <zodbot> The chair is jlebon. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:32:37 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:32:37 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:32:49 <jlebon> #topic roll call
16:34:04 <marmijo[m]> .hi
16:34:04 <spresti[m]> .hello2
16:34:05 <zodbot> marmijo[m]: Sorry, but user 'marmijo [m]' does not exist
16:34:06 <spresti[m]> * .hello
16:34:09 <zodbot> spresti[m]: Sorry, but user 'spresti [m]' does not exist
16:34:09 <mnguyen> .hello mnguyen
16:34:12 <zodbot> mnguyen: mnguyen 'Michael Nguyen' <mnguyen@redhat.com>
16:34:21 <spresti[m]> .hello2
16:34:22 <zodbot> spresti[m]: Sorry, but user 'spresti [m]' does not exist
16:34:27 <spresti[m]> .hello
16:34:28 <marmijo[m]> .hi marmijo
16:34:29 <zodbot> spresti[m]: (hello <an alias, 1 argument>) -- Alias for "hellomynameis $1".
16:34:32 <zodbot> marmijo[m]: Sorry, but user 'marmijo [m]' does not exist
16:34:36 <jlebon> #chair marmijo[m] spresti[m] mnguyen
16:34:36 <zodbot> Current chairs: jlebon marmijo[m] mnguyen spresti[m]
16:35:32 <travier> .hello siosm
16:35:33 <zodbot> travier: siosm 'Timothée Ravier' <travier@redhat.com>
16:35:35 <dustymabe> .hi
16:35:36 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:36:00 <jlebon> #chair travier dustymabe
16:36:00 <zodbot> Current chairs: dustymabe jlebon marmijo[m] mnguyen spresti[m] travier
16:36:29 <jlebon> ok, let's get started!
16:36:38 <jlebon> #topic Action items from last meeting
16:36:53 <jlebon> * dustymabe to verify that booting a compressed kernel on ppc64le works
16:36:56 <jlebon> * jlebon/dustymabe to ask bgilbert if we should create some process for testing newer versions of golang early for our various projects that use it
16:36:59 <jlebon> * dustymabe create a new ticket for us to decide how we want to handle the shutdown timeout change
16:37:02 <jlebon> * jlebon to take our concerns about host key permission migration script failure to sshd package maintainer
16:37:28 <jlebon> #info jlebon took our concerns about hot key permission migration to https://src.fedoraproject.org/rpms/openssh/pull-request/39
16:37:52 <jlebon> dustymabe: i think someone else is looking at the ppc64le bit, right?
16:37:55 <dustymabe> #info Shilpi from our teams verified booting from a compressed kernel works in a VM. Now going to try on bare metal
16:38:07 <jlebon> nice!
16:38:09 <bgilbert> .hi
16:38:10 <zodbot> bgilbert: bgilbert 'Benjamin Gilbert' <bgilbert@backtick.net>
16:38:13 <jlebon> #chair bgilbert
16:38:13 <zodbot> Current chairs: bgilbert dustymabe jlebon marmijo[m] mnguyen spresti[m] travier
16:38:24 <dustymabe> I will point out there has been some more discussion in the BZ as well
16:38:34 <jlebon> #info dustymabe filed https://github.com/coreos/fedora-coreos-tracker/issues/1404
16:38:46 <dustymabe> https://bugzilla.redhat.com/show_bug.cgi?id=2154939
16:38:58 <jlebon> dustymabe: i haven't talked to bgilbert about the golang thing, did you?
16:39:10 <bgilbert> I saw it in the meeting logs
16:39:28 <bgilbert> we should go around updating upstream CI but that's pretty routine.  no specific concerns
16:39:48 <dustymabe> bgilbert++
16:40:18 <jlebon> bgilbert: nice
16:40:33 <jlebon> ok, i think we can move on to meeting tickets
16:40:46 <jlebon> #topic F38 Change: Shorter Shutdown Timer
16:40:48 <jlebon> #link https://github.com/coreos/fedora-coreos-tracker/issues/1404
16:41:29 <jlebon> "A downstream configuration change to reduce the systemd unit timeout from 2 minutes to 45 seconds and send SIGABRT to generate a core dump before SIGKILL."
16:41:48 <travier> This driven mostly by desktop use cases for Fedora Workstation
16:43:04 <dustymabe> I agree
16:43:19 <jlebon> is the plan still to have each variant undo it, or will it only be done for Workstation?
16:43:23 <dustymabe> I wonder if we could or should propose that the change target the desktop variants
16:43:52 <travier> The initial PR was https://src.fedoraproject.org/rpms/systemd/pull-request/85
16:44:31 <travier> but it was changed to https://src.fedoraproject.org/rpms/systemd/c/ba02e904964116b848080ca72243174f4ef3eced?branch=rawhide
16:44:38 <travier> so it affects eveyone by default
16:44:51 <travier> we need to override it explicitely if we want to keep existing values
16:45:04 <jlebon> fun
16:45:25 <jlebon> do we know what server and IoT will do?
16:45:45 <jlebon> if everyone but silverblue takes the default, maybe the default should be changed
16:45:50 <dustymabe> I think I read that server doesn't want the change
16:45:51 <jlebon> s/silverblue/workstation/
16:46:05 <dustymabe> i'm not sure about Fedora Cloud - cc davdunc
16:46:21 <travier> I argued against it being a compile time default in the PR but that did not stick
16:46:40 <travier> Agree it should be just for desktops
16:46:43 <jlebon> i mean, it's trivial for variants to override, but it seems like an odd stance
16:47:27 <jlebon> should we resurface it on the list?
16:47:42 <dustymabe> i think Fedora often gets in this "server versus desktop" problem
16:48:00 <dustymabe> would be nice if we could easily configure each class of system differently
16:48:38 <travier> Well, we have fedora-release packages for each variant that can ship their own tweaks and actually do it today
16:48:52 <dustymabe> "it's trivial for variants to override" -> I think it'd be important to me that each of us variants override consistently (i.e. share the place where the override is made)
16:49:18 <dustymabe> travier: yes, like that but maybe less copy/paste and more shared config
16:49:20 <travier> The additionnal issue will be that the man page will be "wrong"
16:49:32 <travier> we don't ship the man page so this does not affect us
16:50:12 <travier> but if you look at the upstream or Fedora man page, you'll get different values, and you'll have to look at the config on the system + the compiled in default to know the real one
16:50:13 <dustymabe> travier: with the latest versions of the code is it possible for us to put our override in the fedora release package today?
16:50:29 <travier> it should be, have not verifier
16:50:31 <travier> verified*
16:51:01 <dustymabe> maybe a good way to push the conversation forward is to open a PR there and make the change for all server like variants and invite those subteams to weigh in on the PR
16:51:47 <jlebon> +1
16:51:54 <travier> +1
16:52:06 <jlebon> do we have a volunteer for that?
16:52:44 <dustymabe> i'm willing to mentor if anyone is looking to learn
16:52:59 <travier> can mentor as well
16:53:38 <jlebon> nice. maybe we can take it back to #fedora-coreos and see if someone would be interested
16:53:41 <dustymabe> would be good to write a test for this too, just to make sure it doesn't change on us in the future
16:54:03 <dustymabe> jlebon: let's at least get an #agreed going on the path we want to take
16:55:02 <jlebon> #proposal we will submit a PR against fedora-release to undo this change on server variants to try to push the conversation forward
16:55:06 <jlebon> something like that?
16:55:32 <travier> +1
16:56:04 <travier> I'll do it if no-one steps in
16:56:16 <dustymabe> jlebon: yeah, we could be a little more specific
16:56:21 <jlebon> travier++
16:56:31 <dustymabe> for example I think we've decided that we don't want this change even if other variants do
16:56:32 <jlebon> dustymabe: want to suggest a proposal?
16:56:50 <jlebon> ok, let me retry
16:57:08 * nirik[m] notes he argued to server folks to go ahead and stick with default
16:57:18 <dustymabe> nirik[m]: the new default
16:57:20 <jlebon> #proposal we do not want this change in FCOS. we think other server variants don't as well. we will submit a PR against fedora-release to undo this change on server variants to try to push the conversation forward.
16:57:56 <nirik[m]> we are talking about the shorter default stop time right?
16:58:06 <dustymabe> nirik[m]: right
16:58:17 <dustymabe> so you were arguing to get them to accept the new 45s time?
16:58:49 <nirik[m]> yes. I don't think it's actually going to cause that many more problems...
16:59:04 <nirik[m]> it's only going to affect things that took longer than 45s and less than 90 seconds to stop.
16:59:34 <nirik[m]> and those things will dump a core/report to abrt so they can be fixed.
16:59:45 <nirik[m]> All the important things that take a long time already override this in their unit files.
17:00:13 <dustymabe> nirik[m]: i think you are right for COTS software, but units that users wrote themselves maybe not so much
17:00:26 <nirik[m]> postgres/libvirt etc all set it to infinity
17:00:37 <dustymabe> which I guess now that I think about it
17:00:48 <dustymabe> we encourage people to run containers in the FCOS world
17:00:55 <bgilbert> also we don't ship abrt
17:00:56 <nirik[m]> right, but how many are in the window of longer than 45s and less than 90s... but I could be mistaken about that. ;)
17:01:14 <dustymabe> nirik[m]: let me flip the argument the other way
17:01:29 <dustymabe> what's the benefit to FCOS users to timeout at 45 versus 90?
17:01:36 <nirik[m]> do the various container units reset the time?
17:01:39 <dustymabe> I see little upside and potential downside
17:01:48 <nirik[m]> faster shutdown/reboots?
17:02:05 <bgilbert> nirik[m]: only in the case that we're prematurely terminating someone's job
17:02:12 <dustymabe> but you get that at the expense of hard killing someones process
17:02:14 <bgilbert> which is a breaking change for them
17:02:50 <nirik[m]> sure, but then they are aware of the slow shutdown...
17:03:03 <dustymabe> I see clear benefits for laptop/desktop case, not so much in server
17:03:20 <nirik[m]> but sure. I just wanted to note that I think server is just going to stick with default for now. You all of course can do what you feel is best. :)
17:03:32 <dustymabe> oh I see. so they changed their mind?
17:03:38 <dustymabe> and are going to go with 45s?
17:04:06 <nirik[m]> I think so. I argued that, but I don't know if a final decision was yet made.
17:04:43 <dustymabe> jlebon: agreed to your proposal
17:04:50 <dustymabe> either way it will push the conversation forward
17:05:00 <bgilbert> btw, to all the folks involved in this change, _thank you_ for making it a Fedora Change rather than just doing it <3
17:05:07 <bgilbert> we likely would have completely missed it otherwise, until it broke someone
17:05:24 <dustymabe> +1 bgilbert
17:05:29 <jlebon> indeed!
17:05:43 <jlebon> ok let's move on then
17:05:52 <jlebon> #agreed we do not want this change in FCOS. we think other server variants don't as well. we will submit a PR against fedora-release to undo this change on server variants to try to push the conversation forward.
17:05:56 <travier> +1
17:06:04 <jlebon> #topic Fedora CoreOS download page re-design
17:06:07 <jlebon> #link https://github.com/coreos/fedora-coreos-tracker/issues/1387
17:06:30 <jlebon> the draft website has been updated with our feedback
17:06:42 <jlebon> #link https://fedora.gitlab.io/websites-apps/fedora-websites/fedora-websites-3.0/coreos/download/?stream=stable
17:07:34 <dustymabe> i have a few pieces of feedback still
17:07:57 <dustymabe> i didn't notice this up front but just recently
17:07:59 <jlebon> it looks really nice
17:08:14 <dustymabe> when you click on a stream it changes the colors of all the download buttons
17:08:18 <dustymabe> to the color of that stream
17:08:30 <dustymabe> which I think is a positive and a negative
17:08:47 <dustymabe> +: it's more clear it's related to the other stream
17:09:01 <dustymabe> -: I'm not the biggest fan of the bright green color all over the page
17:09:15 <mnguyen> i agree dusty
17:10:04 <spresti[m]> m2
17:10:04 <spresti[m]> The green is a bit brighter?
17:10:04 <spresti[m]> Love the flow more tho
17:10:29 <jlebon> the green is definitely toned down to what it used to be
17:10:44 <dustymabe> we could possibly propose that we keep the colors changing but we make them like a grayscale version of the actual colors at the top
17:10:46 <jlebon> maybe not the buttons, not sure. but the "Sown Downloads" is
17:11:06 <dustymabe> yeah I think the colors at the top are fine now
17:11:17 <dustymabe> just the buttons and text changing is a bit much
17:11:41 <jlebon> dustymabe: wouldn't they all be different close shades of gray?
17:11:54 <jlebon> maybe simpler to just keep them one color
17:12:03 <dustymabe> i think I used the wrong words
17:12:25 <dustymabe> i.e. it would be a grayed out version of green/orange/blue
17:12:47 <jlebon> ahh ok, so less saturated?
17:12:48 <dustymabe> so there would still be a visual indicator of blue/green/orange, but not quite as "loud"
17:13:05 <dustymabe> jlebon: yes, I think that's what I was trying to say
17:13:42 <jlebon> honestly, i'd also be fine to not change those colors at all and match whatever other variants use for those buttons
17:14:06 <jlebon> the arch and stream names are already included in color at the beginning of each section
17:14:58 <jlebon> dustymabe: want to take this back to darknao?
17:15:06 <dustymabe> right. so the two options we are proposing:
17:15:18 <dustymabe> 1. keep colors consistent (I like the blue) for all streams
17:15:49 <dustymabe> 2. use a less saturated (greyed out) version of the colors on the buttons
17:16:36 <dustymabe> does that sound right?
17:16:41 <dustymabe> any objections?
17:16:53 <jlebon> SGTM
17:17:07 <bgilbert> if we keep the colors consistent on the buttons, presumably we should drop the colors from the streams?
17:17:10 <bgilbert> (not sure if that was implied)
17:17:28 <bgilbert> otherwise there'd be e.g. a blue button for downloading green bits
17:17:29 <dustymabe> i was just thinking we keep the colors at the top
17:18:17 <dustymabe> for example, on the `stable` stream view i didn't even really know the colors on the buttons were related to the selected stream - just thought it was part of the theme
17:18:32 <dustymabe> it wasn't until I clicked a different stream that I realized they were related
17:18:36 <bgilbert> eh, I like the color feedback
17:18:41 <dustymabe> right, ok
17:18:44 <bgilbert> making them less saturated seems okay
17:18:51 <dustymabe> so what do you think about: `2. use a less saturated (greyed out) version of the colors on the buttons`
17:18:52 <bgilbert> or making the buttons a color which isn't any of the three stream colors
17:18:54 <dustymabe> +1
17:19:07 <bgilbert> but I'd favor option 2 above
17:19:13 <dustymabe> ok sounds good
17:19:18 <jlebon> WFM
17:19:19 <dustymabe> the other bits of feedback I had
17:19:38 <dustymabe> A. there still isn't a clear indicator in that middle section of which arch is currently selected
17:20:02 <dustymabe> i.e. a border around the currently selected one (or some other visual indicator)
17:20:24 <dustymabe> B. adding the AMI ID to the AWS dropdown (like we did for GCP)
17:20:44 <dustymabe> and then maybe
17:20:56 <bgilbert> yeah, I noticed A. too
17:21:09 <dustymabe> C. for expanding the info for a cloud launchable maybe just make the whole button act as the informational button click
17:21:58 <jlebon> dustymabe: expanding to show all the AMI IDs might be a bit noisy and crowded
17:22:13 <dustymabe> sigh, forgot about the regions :(
17:22:19 <dustymabe> F
17:22:37 <jlebon> for GCP, i like the info button so you know there's something discoverable there
17:22:48 <dustymabe> I still think it's important to have that information there. I NEVER click the cloud launchable button to open the web interface
17:23:19 <dustymabe> jlebon: yeah I'm not proposing we get rid of the info button, but that we just make the whole block act as if you clicked the info button
17:23:30 <bgilbert> +1 jlebon
17:23:40 <jlebon> ack, gotcha
17:23:49 <dustymabe> for AWS I always just grab the AMI ID and then use the CLI or API
17:23:59 <jlebon> dustymabe: you can still do that, no?
17:24:18 <dustymabe> how? by first clicking through to the amazon web console?
17:24:29 <jlebon> did you click on the launch icon?
17:24:29 <dustymabe> I think that's a regressed UX from what we have to day
17:24:38 <dustymabe> oh I see
17:24:43 <dustymabe> just clicked it
17:25:00 <dustymabe> ok - that's different from what we have today
17:25:32 <dustymabe> and also different than the behavior for GCP
17:25:51 <dustymabe> which it needs to be because it needs to know which region you want to target
17:25:59 <jlebon> right
17:26:08 <dustymabe> ok so maybe the proposal is to just at an info button there too, and just have it act the same as the launch button
17:26:45 <dustymabe> i.e. it will pop out with the same info/links to click
17:27:22 <dustymabe> sorry for spending too much time on this
17:27:26 <bgilbert> that doesn't feel great
17:27:27 <jlebon> hmm, two buttons for the same thing is a bit confusing
17:27:44 <dustymabe> ok, forget that proposal then
17:27:54 <dustymabe> how about highlighted selected arch?
17:28:12 <jlebon> we actually don't have that on the old website
17:28:16 <jlebon> (just checked)
17:28:22 <jlebon> but it's good feedback
17:28:36 <jlebon> (we do have a "currently selected stream: x" label though)
17:28:55 <dustymabe> right, but we also don't have `s390x` on the page anywhere if x86_64 is selected
17:29:03 <dustymabe> so there's no ambiguity
17:29:55 <jlebon> sorry, i got confused.  yeah, makes sense to me
17:30:14 <dustymabe> ok cool. I'm done :)
17:30:50 <jlebon> cool. :)  are you ok to take that feedback back to the ticket and darknao?
17:31:09 <jlebon> well, i can do the ticket. not sure if they're watching that or if you have another channel
17:31:09 <dustymabe> as long as people agree with it
17:31:38 <dustymabe> yes
17:32:07 <jlebon> so to summarize: (1) desaturate the buttons and (2) feedback on selected arch?
17:32:30 <dustymabe> yeah and there was also the:
17:32:32 <dustymabe> jlebon: yeah I'm not proposing we get rid of the info button, but that we just make the whole block act as if you clicked the info button
17:32:41 <dustymabe> which I could take or leave
17:32:57 <jlebon> kinda lukewarm on that
17:32:59 <bgilbert> likewsie
17:33:06 <jlebon> it makes it act differently than any of the other boxes
17:33:22 <dustymabe> ok
17:33:26 <dustymabe> 👍
17:34:03 <bgilbert> and (3) this looks great <3
17:34:34 <jlebon> #action dustymabe will communicate our feedback on the website redesign
17:34:39 <jlebon> indeed, really like it!
17:34:46 <jlebon> (please also communicate that :) )
17:34:52 <jlebon> #topic Open Floor
17:35:12 <jlebon> we're a bit over, as usual :)
17:35:33 <jlebon> anyone has anything to bring up?
17:35:49 <dustymabe> not in particular
17:35:54 <dustymabe> new releases rolling out today?
17:36:08 <jlebon> 🎉
17:36:37 <jlebon> alrighty, will close in 30s
17:37:07 <jlebon> #endmeeting