16:31:56 <dustymabe> #startmeeting fedora_coreos_meeting
16:31:56 <zodbot> Meeting started Wed Jan 25 16:31:56 2023 UTC.
16:31:56 <zodbot> This meeting is logged and archived in a public location.
16:31:56 <zodbot> The chair is dustymabe. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:31:56 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:31:56 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:32:00 <dustymabe> #topic roll call
16:32:03 <dustymabe> .hi
16:32:04 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:32:34 <bgilbert> .hi
16:32:35 <zodbot> bgilbert: bgilbert 'Benjamin Gilbert' <bgilbert@backtick.net>
16:33:21 <dustymabe> #chair bgilbert
16:33:21 <zodbot> Current chairs: bgilbert dustymabe
16:33:40 <jlebon> .hello2
16:33:41 <zodbot> jlebon: jlebon 'None' <jonathan@jlebon.com>
16:34:40 <dustymabe> #chair jlebon
16:34:40 <zodbot> Current chairs: bgilbert dustymabe jlebon
16:34:55 <jmarrero> .hi
16:34:56 <zodbot> jmarrero: jmarrero 'Joseph Marrero' <jmarrero@redhat.com>
16:34:59 <dustymabe> #chair jmarrero
16:34:59 <zodbot> Current chairs: bgilbert dustymabe jlebon jmarrero
16:35:32 <dustymabe> small crowd today :)
16:36:42 <dustymabe> I guess we can move forward and see if there's any useful discussion with what we have
16:36:51 <dustymabe> #topic Action items from last meeting
16:36:56 <dustymabe> #info there were no action items from last meeting! 👏
16:37:35 <dustymabe> #topic Fedora CoreOS download page re-design
16:37:40 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/1387
16:38:04 <dustymabe> The websites team has a proposed re-design of our download page
16:38:23 <dustymabe> with a tracking issue for this over in https://gitlab.com/fedora/websites-apps/fedora-websites/fedora-websites-3.0/-/issues/89
16:38:32 <travier> .hello siosm
16:38:33 <zodbot> travier: siosm 'Timothée Ravier' <travier@redhat.com>
16:38:38 <dustymabe> #chair travier
16:38:38 <zodbot> Current chairs: bgilbert dustymabe jlebon jmarrero travier
16:39:05 <dustymabe> I see bgilbert provided some feedback in the websites issue
16:39:16 <aaradhak[m]> .hi
16:39:17 <zodbot> aaradhak[m]: Sorry, but user 'aaradhak [m]' does not exist
16:39:19 <dustymabe> I'm not going to lie, I kind of like our existind downloads page
16:39:25 <dustymabe> existing*
16:39:36 <dustymabe> #chair aaradhak[m]
16:39:36 <zodbot> Current chairs: aaradhak[m] bgilbert dustymabe jlebon jmarrero travier
16:39:49 <travier> We can and should probably push to keep our page as is in the new design
16:40:07 <travier> it's the same web framework so this "should" be mostly a copy paste
16:40:23 <bgilbert> IMO the new design is visually cleaner
16:40:35 <dustymabe> bgilbert: oh?
16:41:11 <jlebon> i like it too personally
16:41:17 <dustymabe> I had the opposite reaction :)
16:41:48 <bgilbert> our current download page has the needed information, but it feels like the page design wasn't done by a designer
16:41:50 <bgilbert> because it wasn't AFAIK
16:41:51 <jlebon> though feel a bit like the cloud launchable option should be more emphasized
16:41:53 <travier> oh, I had not really seen the new design
16:42:05 <davdunc[m> .hi davdunc
16:42:05 <zodbot> davdunc[m: Error: Missing "]".  You may want to quote your arguments with double quotes in order to prevent extra brackets from being evaluated as nested commands.
16:42:23 <bgilbert> zodbot: nested... commands?
16:42:48 <dustymabe> travier: see the pics in the ticket
16:43:05 <travier> It's missing a clue about which arch is "selected"
16:43:18 <bgilbert> travier: it's there, but perhaps underemphasized
16:43:25 <ravanelli> .hi
16:43:26 <zodbot> ravanelli: ravanelli 'Renata Ravanelli' <renata.ravanelli@gmail.com>
16:43:56 <jlebon> bgilbert: interesting that the stream metadata is now no longer dynamically fetched
16:44:03 <travier> pale grey on pale blue is not really empahised yes
16:44:27 <jlebon> would be good to have that back so that at release time, we don't have to wait for the next rebuild
16:44:42 <jlebon> to confirm that everything went well
16:45:00 <bgilbert> does anyone have the live demo link handy?  I know I saw it somewhere but can't find it now
16:45:15 <bgilbert> jlebon: yeah, there was a bit of pushback on that in the ticket, and I wanted to bring it up here
16:45:16 <jlebon> #link https://stg.fedoraproject.org/coreos/download
16:45:21 <bgilbert> ty
16:46:00 <jlebon> yeah, i guess the selected arch should have a different background or color or something
16:46:10 <bgilbert> I think we do care about keeping the live data source.  verifying it is in the release checklist, and also we have the principle that stream metadata is canonical
16:46:13 <dustymabe> note that the new page doesn't really fit on non-wide configurations well (it's squeezed quite a bit)
16:46:15 <bgilbert> what do folks think?
16:46:33 <dustymabe> oh yeah.. live data source is non-negotiable IMO
16:47:15 <jlebon> i think it's worth pushing back, i don't see it as a hard blocker IMO
16:47:30 <travier> +1 for live data source
16:47:37 <dustymabe> I kind of do see it as a hard blocker
16:47:46 <dustymabe> wouldn't we just be creating more work for ourselves?
16:48:21 <travier> We don't want people to come and ask why there is a new release and it's not on the website already
16:48:38 <bgilbert> to clarify: the site is apparently rebuilt every hour, so updates would be automatic with a delay
16:48:43 <bgilbert> but yes, I agree
16:48:48 <jlebon> we're talking about one hour, not e.g. 1 day
16:49:04 <dustymabe> right, unless the site is failing to build (not uncommon)
16:49:06 <jlebon> but definitely let's talk about it
16:49:59 <travier> I'd argue that the one hour rebuild is a hack because there is no change detection?
16:50:06 <dustymabe> travier: now that you've seen the new design - what do you think?
16:50:09 <travier> and that should go away
16:50:47 <travier> it's missing a few "quick links" in the header section to move between the front page, the release notes and the downloads
16:50:49 <bgilbert> I don't suppose they could listen for our fedmsg
16:51:34 <travier> Release notes are missing (likely a know issue)
16:51:41 <bgilbert> known issue, yeah
16:52:12 <davdunc> so the "cloud images" statement is a bit of an overlap with the other edition.
16:52:30 <davdunc> maybe "public cloud images"
16:52:44 <davdunc> so that you aren't confusing location with edition.
16:53:13 <bgilbert> well, if we're still putting the "for cloud operators" images in that section, OpenStack isn't public cloud
16:53:25 <davdunc> managed. yes.
16:53:40 <bgilbert> "cloud images" has a pretty common meaning though?
16:53:50 * davdunc does it? it confused me.
16:54:02 <dustymabe> I'm thinking not as many people love the old download page as much as I do
16:54:06 <jlebon> davdunc: it does say "Fedora CoreOS" beside the download link though :)
16:54:28 <travier> the big logo is not great (cosmetic)
16:54:41 * davdunc true.
16:54:55 <dustymabe> The old download page is simple and gives you all the information you need without anything you don't
16:55:15 <bgilbert> travier: what big logo?
16:55:26 <travier> https://stg.fedoraproject.org/coreos/
16:55:36 <bgilbert> travier: oh, not on the download page
16:55:43 <jlebon> dustymabe: what do you see as redundant?
16:55:50 <travier> yes, sorry
16:55:54 <dustymabe> the only thing I may change about it is the actual download section i.e. Alibaba AWS could match the new style
16:56:20 <bgilbert> dustymabe: to me the new page feels significantly more professional
16:56:27 * davdunc I'd like to see the JSON a little more distinct.
16:56:49 <bgilbert> davdunc: distinct how?
16:57:12 <dustymabe> jlebon: I don't know if redundant is the word to use
16:57:17 <davdunc> bgilbert: maybe color or underscore to emphasize that it's a link.
16:57:22 <dustymabe> but there's just more information presented immediately to the user
16:57:28 <bgilbert> davdunc: ah, I see
16:57:33 <dustymabe> like - we probably don't need to explain what the different arches are
16:57:54 <dustymabe> and there's like 25 links on the download page (which is overwhelming to me)
16:58:06 <dustymabe> whereas the different sections on our old page made it a little more palatable
16:58:10 <davdunc> dustymabe: maybe make the arch details a hint text?
16:58:24 <travier> davdunc: indeed, I had no idea the JSON text was a link :/
16:58:34 <dustymabe> I also light the background coloring a lot more on our old page
16:58:54 <davdunc> yea. The theme colors are great
16:58:56 <dustymabe> the Stable/Testing/Next three wide thing at the top needs to stay on gray background IMO
16:58:59 <travier> (well it's very similar on the old page)
16:59:21 <bgilbert> IMO the new page is more accessible to new users, who are the target audience
16:59:34 <davdunc> bgilbert: agreed!
16:59:35 <bgilbert> it shows everything we have rather than requiring people to notice the tabs mid-page
16:59:43 <bgilbert> it explains itself better
16:59:58 <bgilbert> and the background color helps emphasize the white lozenges which have the actual actionable bits
17:00:24 <jlebon> hmm i do notice though that we can't link to specific sections anymore like we could with tabs
17:00:28 <jlebon> would be good to have that back
17:00:40 <jlebon> and the arches too don't update the URL
17:01:09 <bgilbert> +1
17:01:11 <jlebon> it's useful when linking to someone looking for help to the specific section they should be looking at
17:01:15 <travier> +1
17:01:30 <dustymabe> we lost the info about GCP image family
17:01:52 <bgilbert> dustymabe: +1
17:02:08 <dustymabe> and also the `details` clickable there
17:02:16 <dustymabe> i guess we should start a list for feedback here
17:02:18 <dustymabe> one sec
17:02:52 <dustymabe> https://hackmd.io/BqKhPwwRRXGUqAtUc07_ig?edit
17:03:49 <dustymabe> please add the things you've noticed ^^ (i.e. the discussion from above)
17:03:51 <jlebon> i like that the interface is now uniform with the other editions' download page
17:04:12 <dustymabe> jlebon: yeah that's the most compelling reason IMO, doesn't mean I like it :)
17:04:28 <jlebon> dustymabe: :)
17:07:14 <bgilbert> I was going to write about triggering a site rebuild from a fedmsg, but if the site is broken that won't work
17:07:23 <dustymabe> correct
17:07:43 <dustymabe> basically the situation we are in here is that the rest of fedora only releases new artifacts every 6 months
17:07:52 <dustymabe> so if the site doesn't build for two weeks, no big deal
17:07:58 <bgilbert> yay
17:08:19 <davdunc[m> and the json streams will remain current.
17:08:50 <dustymabe> bgilbert: maybe we could have the site build cache the current release info - and then we dynamically query if it's still current and if it is use that?
17:08:58 <dustymabe> but I don't know if that would be more lightweight or not
17:09:13 <dustymabe> i.e. does the client have to download all of the metadata in order to tell if it's current?
17:09:38 <jlebon> it could also be a partial rebuild for coreos only that happens much faster (but better from a fedmsg)
17:09:43 <bgilbert> dustymabe: the server copy could cache the ETag
17:10:01 <dustymabe> 👍
17:10:41 <bgilbert> that's better from the disabled-JS perspective but I'm not sure I'd suggest it here
17:10:53 <bgilbert> because it means there's a client-side code path which is almost never exercised
17:10:59 <bgilbert> so is relatively likely to break
17:11:06 <dustymabe> on the topic of the background color behind the stable/testing/next at the top.. we think white is best?
17:11:19 <dustymabe> bgilbert: but we would test that client side code path every time we release
17:11:20 <jlebon> bgilbert: agreed
17:11:33 <dustymabe> i.e. there is a step in the checklist that makes sure the download page shows the right info
17:11:41 <dustymabe> and that would probably happen before the 1 hour build
17:11:48 <jlebon> feels complex to have two ways to get the stream info
17:11:59 <bgilbert> anyone making changes to the site would not see the effects of those changes in real time
17:12:02 <bgilbert> only when things break
17:12:16 <dustymabe> ok, bad idea then :)
17:12:17 <bgilbert> and the website has never had active maintenance
17:13:27 <jlebon> dustymabe: are you proposing gray?
17:13:50 <dustymabe> jlebon: that's what the old website has.. i think the contrast of those bright colors with white is a bit harsh
17:14:16 <jlebon> on that topic, i think the green and orange of testing/next was bumped in saturation a bit
17:14:21 <bgilbert> I like it /shrug
17:14:40 <dustymabe> jlebon: now that you mention it
17:14:42 <dustymabe> yeah
17:14:46 <dustymabe> they are
17:14:52 <jlebon> the orange is probably ok, but the green is a little bit too bright IMO
17:15:04 <dustymabe> the orange is significantly less "burnt" orange
17:15:09 <jlebon> but not a big deal :)
17:15:26 <dustymabe> that might help the contrast thing I was highlighting above
17:15:28 <jlebon> dustymabe: no strong opinion on white/gray. maybe we could see a mockup and compare
17:15:34 <jlebon> indeed
17:15:38 <dustymabe> maybe it was that change and not the "on white background" part
17:16:17 <jlebon> e.g. the "Show Downloads" button for testing is a bit harder to read than the others
17:17:03 <bgilbert> green a bit bright, yeah
17:17:13 <aaradhak[m]> +1
17:17:45 <jlebon> i think we have enough feedback for now :)  should we try to tackle another ticket?
17:17:48 <dustymabe> ok anything else before we close this one out?
17:17:51 <dustymabe> yep
17:18:05 <dustymabe> I'll try to put this into our ticket and into the websites ticket
17:18:22 <bgilbert> +1
17:18:32 <jlebon> +1
17:18:37 <dustymabe> I haven't looked at the f38 changes since last time so I'll skip that one
17:18:49 <dustymabe> #topic Boot partition can easily run out of space on upgrade
17:18:53 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/1247
17:19:05 <dustymabe> I've had the meeting label on this one for a while
17:19:36 <dustymabe> so the current status is that there is an open bug against the kernel where we are trying to find out WHY the ppc64le kernel isn't compressed but it is on all other architecutes
17:19:48 <dustymabe> https://github.com/coreos/fedora-coreos-tracker/issues/1247#issuecomment-1357996167
17:20:25 <dustymabe> In the absence of an answer to that question (and hopefully a fix to make it compressed).. could we start pursuing option 2. from https://github.com/coreos/fedora-coreos-tracker/issues/1247#issuecomment-1226150382 ?
17:20:45 <dustymabe> which is basically: https://github.com/ostreedev/ostree/issues/2670
17:20:50 <dustymabe> cc jmarrero from that team
17:21:24 <dustymabe> TL;DR - I kind of do want to start shipping ppc64le in our prod streams like we do for all the other architectures
17:21:43 <dustymabe> which actually is something we should consider for the download page re-design :) - ppc64le is going to be up there too
17:22:35 <jmarrero> sorry kind of busy with something else
17:22:50 <dustymabe> there is the option 3 from that ticket - but that's a whole other ball of wax
17:23:37 <dustymabe> jmarrero: maybe you can bring it up with the team to see if there's any path forward there?
17:23:39 <jlebon> increasing /boot size? i still haven't given up on that option personally :)
17:23:49 <jmarrero> I can do that.
17:23:50 <dustymabe> jlebon: yeah, that's option 3.
17:23:55 <dustymabe> jmarrero++
17:23:55 <zodbot> dustymabe: Karma for jmarrero changed to 2 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:24:05 <jlebon> dustymabe: yup, just confirming
17:24:21 <jlebon> but yes, it'd be tricky to rollout
17:24:34 <jlebon> but i refuse to say impossible :)
17:24:37 <bgilbert> jlebon: do we have any solution for the reinstall clobber problem?
17:24:58 <dustymabe> #action jmarrero to discuss option 2. (oportunistically pruning older deployments if low on space) with his team and get back to us
17:25:51 <jlebon> bgilbert: i don't think so. we'd need to revisit the discussions we had around this
17:25:58 <dustymabe> i'm going to push hard to see if we can just change to using compression for the ppc64le kernel - so maybe that will unblock us
17:26:15 <dustymabe> though I guess one thing we could do is do a postprocess compression of the kernel ourselves?
17:26:19 <bgilbert> yeah.  it seems hard to fix when the problem is encoded in user Butane configs which have been written according to our docs
17:26:19 <jlebon> dustymabe: you could try just submitting an MR and see if you can get more feedback that way?
17:26:20 <dustymabe> I don't know how that would work on upgrades
17:26:39 <bgilbert> dustymabe: do we know that there's no technical blocker to enabling kernel compression?
17:26:57 <jlebon> bgilbert: i think with a deprecation window and enough communications, we should be able to make breaking changes
17:27:14 <dustymabe> bgilbert: we don't - i asked jforbes yesterday about just submitting a PR and he said he was going to try to track down an old ML thread
17:27:36 <dustymabe> bgilbert: but.. I should probably at least try to build a kernel and boot it with compression enabled
17:28:04 <dustymabe> or even just compress it locally and change the grub entry
17:28:11 <jlebon> dustymabe: at the very least, if it gets merged and then reverted at least now we'll know the reason why it wasn't enabled and it can be documented better
17:28:17 <bgilbert> jlebon: breaking changes that clobber your data if you missed the memo aren't good.  at the very least the initrd should detect that you haven't updated your config, and fail
17:28:20 <dustymabe> jlebon: my thoughts exactly
17:28:43 <bgilbert> but I'm not sure the config is expressive enough to do that
17:28:48 <dustymabe> #action dustymabe to verify that booting a compressed kernel on ppc64le works
17:28:58 <bgilbert> anyway, yes, should discuss :-)
17:29:13 <dustymabe> anything else before we move to open floor?
17:29:22 <jlebon> bgilbert: agreed :)
17:29:51 <dustymabe> #topic open floor
17:30:14 <dustymabe> periodic reminder - please add the `meeting` label (or comment to say you want to discuss in a meeting) on any tickets in the tracker
17:30:36 <dustymabe> any items for open floor?
17:32:17 <dustymabe> #endmeeting