16:29:43 <dustymabe> #startmeeting fedora_coreos_meeting
16:29:43 <zodbot> Meeting started Wed Jan  4 16:29:43 2023 UTC.
16:29:43 <zodbot> This meeting is logged and archived in a public location.
16:29:43 <zodbot> The chair is dustymabe. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:29:43 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:29:43 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:29:50 <dustymabe> #topic roll call
16:29:52 <dustymabe> .hi
16:29:53 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:30:36 <marmijo[m]> .hi
16:30:39 <zodbot> marmijo[m]: Sorry, but user 'marmijo [m]' does not exist
16:30:39 <spresti[m]> .hello spresti
16:30:42 <zodbot> spresti[m]: spresti 'Steven Presti' <spresti@redhat.com>
16:30:54 <jmarrero> .hi
16:30:57 <bgilbert> .hi
16:30:57 <zodbot> jmarrero: jmarrero 'Joseph Marrero' <jmarrero@redhat.com>
16:31:01 <zodbot> bgilbert: bgilbert 'Benjamin Gilbert' <bgilbert@backtick.net>
16:31:32 <dustymabe> #chair marmijo[m] spresti[m] jmarrero bgilbert
16:31:32 <zodbot> Current chairs: bgilbert dustymabe jmarrero marmijo[m] spresti[m]
16:33:07 <dustymabe> welcome back all!
16:33:21 <copperi[m]> .hi
16:33:25 <zodbot> copperi[m]: Sorry, but user 'copperi [m]' does not exist
16:33:28 <jlebon> .hello2
16:33:31 <zodbot> jlebon: jlebon 'None' <jonathan@jlebon.com>
16:33:32 <dustymabe> I think we are missing a few people still on holiday, but should have enough to have a productive meeting
16:33:54 <dustymabe> #chair copperi[m] jlebon
16:33:54 <zodbot> Current chairs: bgilbert copperi[m] dustymabe jlebon jmarrero marmijo[m] spresti[m]
16:34:06 <jlebon> welcome back bgilbert!
16:34:23 <bgilbert> thanks!  \o/
16:34:25 <dustymabe> bgilbert++
16:34:34 <dustymabe> #topic Action items from last meeting
16:34:42 <dustymabe> #info There were no action items from last meeting.
16:35:11 <dustymabe> #topic website update
16:35:18 <dustymabe> #link https://discussion.fedoraproject.org/t/fedora-coreos-front-page-revamp-looking-for-feedback/44632/7
16:35:33 <dustymabe> looks like ekidney posted an update to the proposed design for the new page
16:35:52 <dustymabe> incorporating some of our feedback from last time
16:36:31 <dustymabe> should we gather feedback for the new proposal?
16:38:11 * dustymabe taps the mic
16:38:40 <jlebon> i know i initially suggested it, but was thinking the sphere would still have some gloss
16:38:46 <jlebon> just less than before
16:38:54 <dustymabe> One I can think of: "A minimal OS with automatic updates, Scalable and secure." -> Maybe decapitalize "Scalable"
16:39:06 <bgilbert> or s/,/./
16:39:15 <jlebon> i like the less busy look without the floating oranges
16:39:39 <jlebon> bgilbert: +1 i like that better
16:39:49 <dustymabe> bgilbert: +1 - that works for me
16:40:05 <dustymabe> suggestion: "A minimal OS with automatic updates. Scalable and secure."
16:40:12 <marmijo[m]> jlebon: +1 it looks less busy without the stars on the page
16:40:26 <jlebon> i think that was the original intended msg from last mtg
16:40:45 <dustymabe> jlebon: regarding the "gloss" I don't know if it needs more gloss, but I was thinking the blue color on the sphere was a little too dark blue
16:40:57 <dustymabe> so maybe the deglossing had that effect
16:41:10 <jlebon> dustymabe: wait, it is a period in the image. do you see a comma somewhere?
16:41:45 <dustymabe> ahh good point
16:41:49 <dustymabe> my eyes tricked me
16:41:53 <jlebon> dustymabe: yeah, i think that might be it
16:41:59 <dustymabe> it is a period when I click the enlarged version
16:42:12 <spresti[m]> Yeah I agree that the color of the sphere seems to cause the gears to look odd. Though it still looks great!
16:43:18 <dustymabe> spresti[m]: I almost feel like the gears need some "blurring" almost like adding a slightly hazy atmosphere over the whole thing would help :)
16:43:23 <spresti[m]> And regarding the sphere we might want some more smoothing in the bottom left corner, the contrast causes the lines to be apparent.
16:43:27 <dustymabe> "atmostphere"
16:43:53 <jlebon> tiny nit: the poligonal sides on the sphere are showing a bit too much
16:44:10 <dustymabe> jlebon: I think you and spresti[m] have the same comment then?
16:44:19 <jlebon> ahhh yup
16:45:20 <dustymabe> anybody agree or disagree on the desire for more "blur" ?
16:45:39 <ravanelli> .hi
16:45:40 <dustymabe> and.. on just the gears or on the whole thing?
16:45:40 <zodbot> ravanelli: ravanelli 'Renata Ravanelli' <renata.ravanelli@gmail.com>
16:46:16 <dustymabe> #chair ravanelli
16:46:16 <zodbot> Current chairs: bgilbert copperi[m] dustymabe jlebon jmarrero marmijo[m] ravanelli spresti[m]
16:46:21 <spresti[m]> Yeah I agree; blur would help.
16:46:40 <spresti[m]> Almost maybe a boka effect
16:46:54 <dustymabe> :) - that's a new term for me
16:47:06 <dustymabe> but if you think it will help describe what we want I can include it
16:47:51 <jlebon> possibly. feel a bit like there's too much detail in the gears area. not sure if blurring is the right thing vs making it more simplified/stylized, but cool to try
16:48:18 <dustymabe> jlebon: yeah, the level of detail almost draws attention to it, which isn't necessarily what we want
16:48:39 <dustymabe> hence my suggestion of blurring, but that's only because I don't know how to describe the requested change otherwise
16:49:07 <jlebon> i wonder if we want a 3d look at all or just stick with the 2d flat more stylized approach
16:49:22 <jlebon> but if all the other variants will be 3d we don't want to stick out
16:49:57 <dustymabe> yeah, I'm cool with the 3d look since it's only in one place we'll be doing it (not in other places where we use the CoreOS logo)
16:50:31 <dustymabe> should we discuss the icons?
16:50:47 <jlebon> sure
16:50:51 <dustymabe> the new smaller icons (along with the words) looks better IMO
16:51:00 <dustymabe> though I think we're missing at least VMware on that list
16:51:42 <dustymabe> and mabe we want to "Platforms supported by CoreOS" -> "Platforms supported by Fedora CoreOS"
16:52:06 <jlebon> also virtualbox it seems
16:52:24 <jlebon> good catch
16:52:42 <dustymabe> anything other feedback for that bit?
16:52:55 <bgilbert> is there a sort order?
16:52:57 <marmijo[m]> I like the new icons. It's much sleeker and consistent in size.
16:53:08 <dustymabe> marmijo[m]: agree
16:53:12 <bgilbert> it looks like each row is alphabetical but the two rows are unrelated
16:53:37 <dustymabe> bgilbert: yeah, not sure on that one
16:54:05 <bgilbert> we could conceivably do a primary vs. secondary platform distinction, but it looks like this isn't
16:54:06 <dustymabe> so maybe suggest put them all in alphabetical order (i.e. DigitalOcean goes on the top row, etc etc)
16:54:35 <jlebon> WFM
16:54:42 <bgilbert> sgtm
16:54:57 <dustymabe> Though something that is interesting to think about
16:55:32 <dustymabe> We are sorting Microsoft Azure based on `Azure`, but Google Cloud based on `Google`
16:55:37 <dustymabe> should we?
16:55:38 <bgilbert> xref https://github.com/coreos/fedora-coreos-tracker/issues/738
16:56:57 <bgilbert> dustymabe: hmm.  if they choose to put `Microsoft` in their logo I guess it looks less odd to respect that
16:57:02 <bgilbert> even though we usually just call it `Azure`
16:57:10 <dustymabe> right
16:57:39 <jlebon> sounds fine to me
16:57:41 <dustymabe> I don't have a strong opinion there, it could just confuse someone who was trying to sort it alphabetically
16:58:01 <dustymabe> ok shall we move on to the next topic for today?
16:58:07 <jlebon> +1
16:58:49 <dustymabe> #topic Create container tags for each FCOS release
16:58:54 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/1367
17:00:05 <dustymabe> I think this is probably part of us completing the puzzle that is OSTree Native Container work, but we could probably come up with a shorter term solution
17:01:37 <dustymabe> one thing I like about what we have now is that the tags in quay isn't overwhelming: https://quay.io/repository/fedora/fedora-coreos?tab=tags
17:02:13 <dustymabe> I wish there was a way to do hidden tags or something (that don't show up in the web UI)
17:03:05 <jlebon> yeah, that'd be neat
17:03:30 <jlebon> it also makes listing tags from the cmdline less spammy
17:04:06 <jlebon> but not sure that alone is worth not tagging things
17:04:13 <bgilbert> I see two issues here: managing the GC lifetime and making it easier for users to pin old releases
17:04:25 <dustymabe> bgilbert: correct
17:04:34 <bgilbert> #2 is not a thing, and #1 is an implementation detail that ideally we'd solve in another way
17:04:45 <bgilbert> but, Quay
17:05:39 <bgilbert> the fundamental problem with tags is that people would use them
17:06:24 <jlebon> bgilbert: let's have a service that shuffle tag names around daily?
17:06:29 <bgilbert> hah
17:06:38 <bgilbert> does anyone happen to know the maximum Quay GC timeout?
17:07:09 <dustymabe> bgilbert: I think the default is to not GC
17:07:13 <bgilbert> I mean, we could create tag names that are just an abbreviated image hash
17:07:27 <dustymabe> i.e. if a tag exists then it won't get garbage collected
17:07:43 <dustymabe> unless there is a specific label on the image telling quay when it's safe to GC
17:07:50 <bgilbert> dustymabe: it isn't
17:08:02 <bgilbert> looks like a month
17:08:04 <bgilbert> it's an account setting
17:08:19 <dustymabe> "it isn't" - mind expanding on that?
17:08:50 <bgilbert> well, okay, the wording is weird
17:08:54 <bgilbert> #link https://access.redhat.com/documentation/en-us/red_hat_quay/3/html/use_red_hat_quay/working_with_tags#tag-expiration
17:09:24 <bgilbert> but jdoss reports in the bug that untagged SHAs are in fact GCed
17:09:25 <dustymabe> right
17:09:44 <dustymabe> well. I guess it depends and might need some probing
17:09:58 <bgilbert> Colin just suggested in the bug (but not here?) that we could move older images to a separate repo
17:10:01 <dustymabe> in the web UI right now I can see the option to "revert to" older tags
17:10:14 <dustymabe> looks like as far back as Dec 21
17:10:39 <dustymabe> but... is that user facing? i.e. could the user still pull that old sha?
17:11:22 <bgilbert> the issue says "I can't pull an older image by SHA because quay.io seems to prune untagged SHAs over time"
17:11:23 <dustymabe> either way I don't know if we want to rely on that here rather than just adding tags to images (i.e. "immutable tags")
17:11:42 <bgilbert> I could be okay with tags based on image hashes
17:11:51 <bgilbert> it does still clutter the tag list
17:11:57 <dustymabe> bgilbert: right, but was he trying to pull one older than the GC threshold? we can test this out and see
17:12:56 <dustymabe> maybe let's roll back to your original dissection bgilbert
17:13:04 <dustymabe> #1 managing the GC lifetime
17:13:08 <dustymabe> #2 making it easier for users to pin old releases
17:13:26 <dustymabe> regarding #2 - you see that as an anti-goal ?
17:14:23 <walters> I think we need to accept reality that most people are going to run stable, and hit a bug, and want to temporarily be able to run stable - 1 at least
17:14:33 <bgilbert> absolutely.  it's been an anti-goal on every other platform; container images shouldn't be different
17:14:46 <walters> We could even optimize that by having a stable-previous tag
17:14:47 <bgilbert> walters: sure, I'm not arguing that we should aggressively GC
17:15:12 <dustymabe> I think there is one difference here that's worth highlighting
17:15:38 <dustymabe> so in the past the user is running say the `stable` stream and then a bug comes in that breaks them in some way
17:15:42 <walters> But other than that, I'd still lean to relatively aggressively moving things to fedora-archive
17:16:01 <dustymabe> they then `rpm-ostree rollback` and open a bug and hopefull it gets fixed soon
17:16:12 <jlebon> and can disable zincati if needed
17:16:16 <dustymabe> this is all happening client side
17:16:32 <walters> well yes, but notably we also aren't GCing the ostree repo right?
17:17:01 <dustymabe> in jdoss case here, AFAICT FCOS is an input to his custom build (so this isn't a client side thing)
17:17:58 <dustymabe> so he's pinning (just like the user in the previous case would `rpm-ostree rollback` to pin), but he needs to pin at a different stage
17:18:10 <bgilbert> the archive approach strikes me as a weird balance.  we normally don't change the machine-readable identifier to old releases; we leave them where they are, and then (in concept) GC them
17:18:38 <walters> so they could in theory be explicitly deploying versions there too
17:18:52 <dustymabe> walters: we are starting to GC the ostree repo, but our policy right now for production streams is to not prune any content from those
17:19:03 <bgilbert> with AWS or GCP, if you want to pin to an old release, you have to look up the identifier and then you're free to use it
17:19:10 <bgilbert> that seems about right to me
17:19:24 <dustymabe> yeah, that's fine I think
17:19:40 <jlebon> bgilbert: unless images are pushed to both repos from the start
17:20:02 <bgilbert> (and we don't publicize a historical lookup service)
17:20:08 <bgilbert> jlebon: true
17:20:23 <bgilbert> how would we document that, though?  "repository of old things you're not supposed to use"?
17:20:32 <dustymabe> what's the use case for `fedora-archive` ?
17:20:32 <walters> the archive approach 1) discourages people from using much older versions 2) specifically optimizes the UI (and efficiency of things that fetch tags) from the registry.  The case of 2) is different for cloud providers
17:20:57 <walters> There's no default UI in GCP that shows you the version history of fcos
17:21:02 <bgilbert> walters: I'm not sure it does (1) though.  people might just get in the habit of pinning tags from the archive
17:21:08 <jlebon> one question is whether pull-by-digests are scoped to the repo. it probably is, but it's worth checking
17:21:18 <walters> bgilbert: we'd still GC things from the archive
17:21:38 <bgilbert> I agree with dustymabe.  how would we frame the use case?
17:22:21 <bgilbert> ...unless we just leave the archive undocumented.  in which case, sure
17:22:32 <bgilbert> that's not terrible actually
17:22:35 <walters> The archive fills the same role as the build browser today
17:23:00 <dustymabe> to be clear I'm not opposed to people being able to pull old content. I just don't really want to manage another quay repo
17:23:56 <jlebon> another approach is to keep the tags in the prod repo, but only for prod streams. that should cut down a lot on the number of tags
17:23:59 <walters> Well, I think the same use case applies to quay.io/fedora/fedora i.e. the app base image, and we could implement it using the same tools
17:24:29 <dustymabe> if we could still pull the yet to be GC hashes today then we'd all be happy I think (and we could extend the GC expiration to something longer)
17:25:01 <walters> On that topic, worth noting that registry.access.redhat.com/ubi8/ubi specifically maintains a bunch of tags that I think are also being pruned
17:25:25 <bgilbert> proposal: the existing quay repo continues as is.  we add a new archive repo with versioned tags and GC; build browser container links point to the archive but it's otherwise undocumented
17:25:42 <bgilbert> and new builds get pushed to both repos
17:26:12 <walters> Once we have fedora-archive we can also stop putting .ociarchive files in S3, and have the cosa metadata just reference the image...
17:27:23 <walters> +1 to proposal from me
17:27:52 <jlebon> i think i'm ok with that, but i'd like to explore the use case a bit more ideally
17:28:06 <dustymabe> so the archive at this point is just so we don't clutter the tag namespace? or also being explicitly undocumented is a "feature" ?
17:28:24 <bgilbert> dustymabe: both of those
17:28:28 <jlebon> if we're eventually going to transition to native containers and support layering, this will become much more common. is this the UX we want?
17:28:40 <walters> I'd say the latter is more clearly delineating support; fedora-archive is "not supported"
17:28:57 <bgilbert> walters: +1
17:29:18 * dustymabe notes we could probably bikeshed on naming
17:30:28 <dustymabe> jlebon: do you want to take away some homework to explore your "more idealistic" solution?
17:30:37 <dustymabe> and for now I'll stick the current proposal into the ticket?
17:31:26 <jlebon> i don't have a more idealistic solution. :) i'm just unsure whether we're not going to end up having to unofficially support these tags anyway
17:31:44 <bgilbert> jlebon: how so?  our current answer for e.g. bugs against old releases is "upgrade to latest"
17:32:03 <jlebon> bgilbert: right, the question is what happens if latest is buggy?
17:32:07 <dustymabe> bgilbert: I think we have to be practical
17:32:21 <bgilbert> same as now: pin if you want, and we'll fix it
17:32:22 <dustymabe> people stay on "not latest" all the time because of bugs
17:32:33 <dustymabe> bgilbert: right
17:32:42 <bgilbert> I'm not saying we can't tell anyone about the repo, just that it shouldn't be in formal docs
17:32:54 <jlebon> bgilbert: it doesn't make sense to make pinning unsupported though if that's what we recommend
17:33:07 <dustymabe> honestly I would be fine with what we have right now (pull the container from the builds browser and use it), but I think registries and build systems need a registry URL
17:33:14 <jlebon> maybe i'm just not understanding the wording around this
17:33:49 <bgilbert> jlebon: doesn't it?  IMO there's usually a set of operations that exist, and are sometimes used/recommended by experts, but officially Not Recommended
17:33:54 <dustymabe> i.e. `FROM https://foo/fedora-coreos-XYZ.ociarchive` doesn't work
17:34:38 <jlebon> bgilbert: right, my point is though that when layering becomes officially supported, we'll potentially have a lot more people taking this route
17:34:47 * walters has to step out, thanks all for the discussion!
17:34:52 <bgilbert> thanks walters!
17:34:57 <jlebon> walters: see ya!
17:35:16 <bgilbert> jlebon: sure
17:35:19 <dustymabe> ok - we're running over time.
17:35:35 <jlebon> right now, it seems ok because it's all experimental and we're ok suggesting non-ideal solutions to early adopters
17:35:39 <dustymabe> maybe let's a few of us get together to discuss more and come up with a more concrete proposal to discuss next time?
17:35:39 <bgilbert> it's free software, I don't want to make anything impossible, just draw a clear line where it's discouraged
17:36:07 <bgilbert> jlebon: fwiw I don't see this as a temporary fix
17:36:50 <bgilbert> +1 to moving on
17:36:51 <jlebon> bgilbert: right, that's what i'm getting at. it wasn't clear whether we were discussing a short-term thing or not. if not, then it seems like it could warrant more discussion.
17:36:58 <dustymabe> #action jlebon bgilbert walters dustymabe get together to work on proposal for short term and longer term solution to the problem of being able to pull older FCOS releases from a registry
17:37:06 <bgilbert> jlebon: +1
17:37:28 <jlebon> sorry for dragging this :|
17:37:54 <bgilbert> jlebon: discussion is good :-)
17:37:57 <dustymabe> no worries. It's what we're here for, to drive to resolution outstanding issues.
17:38:05 <dustymabe> otherwise they linger forever :)
17:38:08 <dustymabe> #topic open floor
17:38:10 <bgilbert> 100%
17:38:30 <dustymabe> one thing I want to do next week is revisit our FCOS priority list
17:38:47 <dustymabe> should we try to do a video meeting for that? or IRC work well enough?
17:38:50 <dustymabe> we've done it both ways in the past
17:39:08 <jlebon> video could be cool. we haven't had those in a while!
17:39:11 <bgilbert> I don't prefer video meetings but I think either way works
17:39:45 <dustymabe> +1 and -1 for video
17:39:47 <dustymabe> anyone else ?
17:40:12 <spresti[m]> I tend to lean more towards video
17:40:41 <dustymabe> video it is :)
17:41:02 <dustymabe> #info we will attempt to have a video meeting next week to revisit our priorities and discuss progress on vairous items we've been working on
17:41:07 <dustymabe> any other topics for open floor today
17:41:10 <dustymabe> sorry we are over time
17:42:20 <dustymabe> #endmeeting