`moss compose` for transmuting serpent root transactions into OCI compatible images (overlayfs?)

[ermo]

ermo

Reilly Brogan
I also posted it because I brought it up in the context of Serpent tooling, though we realized it probably wouldn't work for us

It feels like we invented some cool tech that someone else then built independently and now OSTree is gonna use it.
(built/discovered independently I mean)
for all intents and purposes, composefs is similar to what we're doing with serpent, except this is using erofs
and has dm-verity like properties.
Ikey Doherty
It's OK for them to be inspired :p
We're going a step further imho
By having a well defined container format and unpack process
Rather than piggybacking on other formats with a directory layout
ermo
What bugs me personally, is that there's no trivial way to use "pseudo-oci" images with serpent
but maybe ... what if composefs-like functionality allowed access to consume existing hardlink versions of moss roots?
Ikey Doherty
I don't know what that means
ermo
so, we already have a moss store w/content-addressed-storage
what if we did a reverse, where we somehow used composefs to build "on-the-fly" OCI images, but without changing anything on disk, just a purely additive operation in terms of OCI-required metadata?
then an OCI image becomes "use this root, calculate this extra cruft that oci requires, mount that extra cruft as a thin composefs layer, done -- we can do both."
Ikey Doherty
Surely we can use moss install -D to provision a root
And set up a shared cache
Or am I being thick ?
ermo
no, you're not.
My point is that OCI requires a different CAS algorithm
Ikey Doherty
Oh
ermo
i.e. XXH3_128 is what we use, but OCI mandates something else
Ikey Doherty
So transmute our store into an oci format image
ermo
but the point about shared cache is good -- and yes, "transmute" is the word I was looking for
Ikey Doherty
Seems doable and I'd love to tackle containers with moss
As we have the natural advantage there imho
ermo
when you're building an OCI image, it's ok if it takes time to calculate OCI-endorsed hashes -- because that takes time for everyone doing OCI compatible images.
Ikey Doherty
Ie not dumb old school PM
ermo
but what would happen is that it's essentially a function that maps from "OCI-hash" -> filename (hardlink) -> XXH3_128-hash (.moss store)
Ikey Doherty
Well we could use moss to link the foreign store and add accountancy to speed up subsequent construction
ermo
something like that
and yes, it is exactly an accounting task
Ikey Doherty
OK so with clap this seems easy for us to add
And I catch your drift
So if you wanna record the task and assign to me
We'll make it an early priority
ermo
I am not sure this is exactly an MVP thing, but it will likely pay to have it on the radar at least...?
also, fuck, now it's in Solus Devel and not serpent history. FML.
Ikey Doherty
Lmao
Ikey Doherty
My plan today is get kids to park, burn them out early
moss compose..
Hmm
Too on the nose? XD
ermo
lol, no, that'd be awesome xD
essentially, I'd want moss to be able to build a transaction, then have moss build e.g. the files for an overlayfs with the OCI crap, then mount that same overlay into a container on top of the root-transaction.
"or something..."