that's sounds super cool! I'm a SysDE at Amazon, just burn few cycles here when I can because I love
that's sounds super cool! I'm a SysDE at Amazon, just burn few cycles here when I can because I love open source and containers in general 
Jlol we're all connected
Ait's very nice group of people here 
POh cool. I was an SDE at Amazon (part of the robotics org), up until the recent layoffs 
AOh sorry to hear, I hope you land on your feet - I'm part of AFT, not as cool
PThanks! Yeah I think I'll probably be fine, just really starting to get into looking though, took a few months off to just not worry about things and finally go see some friends across the country etc.
I was technically part of AT (despite being on the east coast), got to do a bunch of infrastructure/edge device management stuff that was a lot of fun.
I was technically part of AT (despite being on the east coast), got to do a bunch of infrastructure/edge device management stuff that was a lot of fun.
JI'm here on a transitionary "don't have a job" too, so it's a nice support group.
J@bsherman ok I understand what we need to do to make new keys, I have dad and gaming clan commitments tonight though
BHuzzah!
JI think if someone can whip up an announcement in the nvidia forum section with the link to the instructions and stuff and then we can edit/fix it up later, I have to afk for a bit
Jor hackmd up a draft
BI assume that new private key is in the org-level secrets, right? 
Jyeah, same date format, I did that first.
BGitHub
Jorge regenerated the new akmods key to include meaningful CN, "ublue akmods", instead of the default "akmods local singing CA".
For #100
For #100
ASorry if anyone's tried to contact me. I'm a bit sick at the moment. You gave me a laugh with this though:
Who was doing the singing? Jorge?
instead of the default "akmods local singing CA".
Who was doing the singing? Jorge?
AI've also discovered that we can shrink our OCI downloads. Possibly by quite a lot. I can't do anything at the moment, too tired. But I committed some earlier work that takes care of that for
https://github.com/orgs/ublue-os/projects/1/views/1?pane=issue&itemId=28591278
startingpoint and added to the board to track it for the other repos:https://github.com/orgs/ublue-os/projects/1/views/1?pane=issue&itemId=28591278
JI was under the impression that we wanted more layers not less
J@bsherman ok I'm back now and can work on announcement stuff
Byes and no, first of all standard oci ideas dont work here been there tried that
Bfirst of all more layers more better for us, unlike with general OCI usage where preferably you would have as little layers possible even just one
Balso we create 10 layers on top of about 50 layers that come from our base image
Bnext fun fact only way to properly ensure size doesnt grow from caches and such is to delete them during same run command as creates them as in some (but not all) cases as soon as that run command ends that layer is set in stone and doesnt realy change
Cyeah deleting caches in the same command makes sense since it creates diffs that force new downloads for those layers
Cbvut I think j0rge is right you want more layers in general since there's more chances to have duplicate layers that you can skip downloading after the first image is downloaded
Bin our case yes in general oci not realy
Bin general OCI you want to have as little layers as possible with most commonality in your stack, but we are not doing services we are doing os where certien things dont matter
Balso i dont think those caches are actually costing us that much
Jbut either way we'd need to wait to do what their team recommends as far as layers go
AMore layers for actual installed packages, yes. Splitting packages is a good thing.
What we are doing right now is not a good thing.
We are currently having:
- Totally useless layers (like
- Layers full of RPM packages and cache files and temp files. Probably shipping like 200mb of useless data on every uBlue image at the moment.
What we are doing right now is not a good thing.
We are currently having:
- Totally useless layers (like
mkdir something).- Layers full of RPM packages and cache files and temp files. Probably shipping like 200mb of useless data on every uBlue image at the moment.
Blayers dont matter
Bnumber of layers
Aostree downloads all OCI layers when it downloads our images, and then merges the data into ostree.
We could probably save a few hundred megabytes per daily system update by fixing these things.
We could probably save a few hundred megabytes per daily system update by fixing these things.
Bit doesnt download all layers
Bit just downloads updated layers, how do i know becuase thats interesting to me becuase i used to work in optimizing oci images
AWe have layers that do things like: Install 50 packages, cache RPMs in
Later layers say
But the OS still downloads both layers. So uBlue is downloading let's say 200mb of useless RPM cache files every day, because they're still inside the earlier layers due to our unoptimized Containerfiles.
/var/cache.Later layers say
delete /var/cache/*.But the OS still downloads both layers. So uBlue is downloading let's say 200mb of useless RPM cache files every day, because they're still inside the earlier layers due to our unoptimized Containerfiles.
Byes deleting caches should be a thing and it should happen in a same layer
Bin which it is created yes
AExactly, and that is what I am saying.
AAnyway that's what the tracking issue is about.
Bwell to properly optimize for wire download what would we need to do is for each package have its own run command which then goes into deleting cache or more properly just delete /var everytime becuase its actually problem to have it anyway
PThe idea being that that way a single package having a difference means you only redownload the layer with just that package, rather than a layer containing 50 other unchanged packages too, I assume
AYep, but there's one problem that brian and I talked about that we're not sure about:
- The RPM database is stored in every layer where a
- I suspect that Silverblue OCI upstream builds their layers in a smarter way with some other tools, which properly caches files separately from the RPM database?
- The RPM database is stored in every layer where a
rpm-ostree install command executes. So if anything in an earlier RPM layer updates the RPM cache, or file timestamps, we'd end up with new layers anyway.- I suspect that Silverblue OCI upstream builds their layers in a smarter way with some other tools, which properly caches files separately from the RPM database?
AThey're also working on new tools that will automatically diff files and only generate layers for modified files (I'm getting tons of emails, they're working hard at it). Hopefully F39 or F40...
Byea they are working on some better optimizations for oci builds
Phttps://youtu.be/QaKl5z6dFlM?t=209 (which got linked in #
general ) mentions "responsible chunked" images from
general ) mentions "responsible chunked" images from ostree compose image, though I'm not sure exactly how that worksJa month ago, how did we miss this!
AAwesome, that video looks like it's about all of this. Perhaps it explains how they're solving the RPM db stuff.
AI think it requires a tool that's aware of the RPM db and generates layers like:
- 1 layer: files from X packages; NO RPM db
- 1 layer: files from Y packages; NO RPM db
- final layer: the merged RPM db
And only updating the separate layers if files from packages are changed.
- 1 layer: files from X packages; NO RPM db
- 1 layer: files from Y packages; NO RPM db
- final layer: the merged RPM db
And only updating the separate layers if files from packages are changed.
AGonna watch that whole video but not atm, still sick. 
Jyeah drink water!
