bvut I think j0rge is right you want more layers in general since there's more chances to have dupli

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

Arcitec•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

Arcitec•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

Arcitec•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

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

Exactly, and that is what I am saying.

Arcitec•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

Arcitec•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 install

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?

Arcitec•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!

Arcitec•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.

Arcitec•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.

Arcitec•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!

Arcitec•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...

Arcitec•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...

Arcitec•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

Arcitec•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...

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

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

Arcitec•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

Arcitec•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?

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

Sure yeah

Jj0rge hopefully all the info is in the ticket

Arcitec•5/19/23, 12:07 AM

I see, so the installer is rewriting the URL to docker://docker://. But that doesn't seem to be the actual issue anyway, they quoted docs which say it's equivalent.

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

bsherman•5/19/23, 12:08 AM

do you need something from me on this? the main thing I know is missing was when I discovered this:

https://github.com/ublue-os/isogenerator/issues/64

I don't know if we want that sorted before announce or no

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

Where do we put the keys in this repo?

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

like is it just inline replacing the files?

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

https://github.com/ublue-os/isogenerator/tree/main/installer/securebootkeys

GitHub

isogenerator/installer/securebootkeys at main · ublue-os/isogenerator

An action to generate custom ISOs of OCI images. Contribute to ublue-os/isogenerator development by creating an account on GitHub.

Jj0rge Where do we put the keys in this repo?

bsherman•5/19/23, 12:09 AM

no, not a replace... we need both, and to import both, I can handle it, just wondering if we want it wrapped up before announce

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

To my understanding: the actual issue is ostree supports both ostree-unverified-image:registry:ostree-unverified-image:registry: and ostree-unverified-image:docker://ostree-unverified-image:docker://, but discover only currently expects ostree-unverified-registry:ostree-unverified-registry:, not anything else, so ostree-unverified-image:registry:ostree-unverified-image:registry: or ostree-unverified-image:docker://ostree-unverified-image:docker:// which should both be equivalent cause it to not work properly.

bvut I think j0rge is right you want more layers in general since there's more chances to have dupli

Similar Threads

Similar Threads

Similar Threads