I've also discovered that we can shrink our OCI downloads. Possibly by quite a lot. I can't do anyth

I'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

startingpoint

startingpoint

startingpoint

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

j0rge•5/18/23, 11:30 PM

I was under the impression that we wanted more layers not less

j0rge•5/18/23, 11:33 PM

@bsherman ok I'm back now and can work on announcement stuff

AArcitec I've also discovered that we can shrink our OCI downloads. Possibly by quite a l...

Bigpod•5/18/23, 11:33 PM

yes and no, first of all standard oci ideas dont work here been there tried that

Bigpod•5/18/23, 11:34 PM

first 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

Bigpod•5/18/23, 11:35 PM

also we create 10 layers on top of about 50 layers that come from our base image

Bigpod•5/18/23, 11:37 PM

next 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

CyberGlitterhoof•5/18/23, 11:37 PM

yeah deleting caches in the same command makes sense since it creates diffs that force new downloads for those layers

CyberGlitterhoof•5/18/23, 11:39 PM

bvut 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

CCyberGlitterhoof bvut I think j0rge is right you want more layers in general since there's more c...

Bigpod•5/18/23, 11:39 PM

in our case yes in general oci not realy

Bigpod•5/18/23, 11:40 PM

in 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

Bigpod•5/18/23, 11:43 PM

also i dont think those caches are actually costing us that much

j0rge•5/18/23, 11:46 PM

but either way we'd need to wait to do what their team recommends as far as layers go

Jj0rge I was under the impression that we wanted more layers not less

ArcitecOP•5/18/23, 11:47 PM

More 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 mkdir somethingmkdir 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.

AArcitec More layers for actual installed packages, yes. Splitting packages is a good thi...

Bigpod•5/18/23, 11:47 PM

layers dont matter

Bigpod•5/18/23, 11:47 PM

number of layers

BBigpod layers dont matter

ArcitecOP•5/18/23, 11:48 PM

ostree 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.

Bigpod•5/18/23, 11:48 PM

it doesnt download all layers

Bigpod•5/18/23, 11:49 PM

it just downloads updated layers, how do i know becuase thats interesting to me becuase i used to work in optimizing oci images

ArcitecOP•5/18/23, 11:49 PM

We have layers that do things like: Install 50 packages, cache RPMs in /var/cache/var/cache.

Later layers say delete /var/cache/*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.

Bigpod•5/18/23, 11:49 PM

yes deleting caches should be a thing and it should happen in a same layer

Bigpod•5/18/23, 11:50 PM

in which it is created yes

ArcitecOP•5/18/23, 11:50 PM

Exactly, and that is what I am saying.

ArcitecOP•5/18/23, 11:50 PM

Anyway that's what the tracking issue is about.

Bigpod•5/18/23, 11:53 PM

well 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

BBigpod well to properly optimize for wire download what would we need to do is for each...

pythoner6•5/18/23, 11:54 PM

The 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

Ppythoner6 The idea being that that way a single package having a difference means you only...

Bigpod•5/18/23, 11:54 PM

yes

ArcitecOP•5/18/23, 11:55 PM

Yep, 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 rpm-ostree installrpm-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?

ArcitecOP•5/18/23, 11:55 PM

They'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...

Bigpod•5/18/23, 11:56 PM

yea they are working on some better optimizations for oci builds

pythoner6•5/18/23, 11:57 PM

https://youtu.be/QaKl5z6dFlM?t=209 (which got linked in #

general ) mentions "responsible chunked" images from ostree compose imageostree compose image, though I'm not sure exactly how that works

j0rge•5/18/23, 11:58 PM

a month ago, how did we miss this!

ArcitecOP•5/18/23, 11:58 PM

Awesome, that video looks like it's about all of this. Perhaps it explains how they're solving the RPM db stuff.

ArcitecOP•5/18/23, 11:59 PM

I 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.

ArcitecOP•5/18/23, 11:59 PM

Gonna watch that whole video but not atm, still sick.

j0rge•5/19/23, 12:00 AM

yeah drink water!

ArcitecOP•5/19/23, 12:00 AM

Yeah got the ice water bottle here. It helps.

j0rge•5/19/23, 12:00 AM

I know we'll be in a preso at some point because one of them PMed me asking if we'd be cool with it

pythoner6•5/19/23, 12:00 AM

Was just watching it myself, I don't think it really gets too much into the details there, the bit about compose image was just mentioned in passing. But an interesting watch regardless

j0rge•5/19/23, 12:01 AM

I have found that every video is important because there's just too much for a single team to consume so we need every single bit of info we can get

Jj0rge I know we'll be in a preso at some point because one of them PMed me asking if w...

ArcitecOP•5/19/23, 12:01 AM

That's so cool. I look forward to the explosion in popularity as we approach critical mass.

Jj0rge I have found that every video is important because there's just too much for a s...

ArcitecOP•5/19/23, 12:02 AM

Yeah. Ideally, someone from upstream gets interested enough to join us and help out with our infrastructure. So to achieve that, we need more growth. To get more growth, we need ads. To get alluring ads, we need to offer people something useful. To offer something useful we just need to keep doing what we're doing and getting better every day!

j0rge•5/19/23, 12:02 AM

I'd like to do things like fix the broken ISOs and stuff before we deep dive into this stuff though

ArcitecOP•5/19/23, 12:02 AM

business speech mode

Jj0rge I'd like to do things like fix the broken ISOs and stuff before we deep dive int...

ArcitecOP•5/19/23, 12:02 AM

Yeah I heard the ISOs don't retry during download failures for example. :S

ArcitecOP•5/19/23, 12:04 AM

It's just a kickstart script so I dunno how we could solve that. Checking exit code and retrying a few times?

j0rge•5/19/23, 12:04 AM

I mean this one: https://github.com/ublue-os/main/issues/132

GitHub

Plasma Discover invalid reference for OCI when installed using the ...

What happened? When using the iso to install ublue a rpm-ostree-backend error occurs mentioning invalid reference for OCI container ostree format. Relevant log output $ plasma-discover rpm-ostree-b...

j0rge•5/19/23, 12:04 AM

the installer issue is Anaconda, not us

ArcitecOP•5/19/23, 12:05 AM

That's strange, docker://docker://?

j0rge•5/19/23, 12:05 AM

hopefully all the info is in the ticket

Ppythoner6 I'd bet that could be what's happening based on <https://github.com/ostreedev/os...

j0rge•5/19/23, 12:06 AM

can you toss the results of your findings in the issue if you don't mind?

I've also discovered that we can shrink our OCI downloads. Possibly by quite a lot. I can't do anyth

Similar Threads

Similar Threads

Similar Threads