<apollo13>
walters: wow lovely, thank you for those two links
jpn has joined #fedora-coreos
<guesswhat[m]>
Hey, anyone tried podman from testing-devel stream? Seems that podman.service can not start due to Error: mkdir /overlay: operation not permitted
Betal has quit [Quit: WeeChat 3.8]
jpn has quit [Ping timeout: 248 seconds]
<apollo13>
I have another question about ostree archive repos. Assume I build an ostree commit and sync that to s3. Then I throw away the local stuff and build a new commit with new packages and resync that to s3. Will that work?
<apollo13>
so I guess the main question is if the repo is kind of "append-only" or if I need to have the existing repository checked out since it has to merge some file contents
Eighth_Doctor has quit [*.net *.split]
vladan[m] has quit [*.net *.split]
copperi[m] has quit [*.net *.split]
miabbott[m] has quit [*.net *.split]
lorbus has quit [*.net *.split]
uny[m] has quit [*.net *.split]
aleskandro[m] has quit [*.net *.split]
sgallagh has quit [*.net *.split]
thomasfedb has quit [*.net *.split]
thomasfedb has joined #fedora-coreos
thomasfedb has quit [Changing host]
thomasfedb has joined #fedora-coreos
vladan[m] has joined #fedora-coreos
aleskandro[m] has joined #fedora-coreos
uny[m] has joined #fedora-coreos
sgallagh has joined #fedora-coreos
lorbus has joined #fedora-coreos
Eighth_Doctor has joined #fedora-coreos
miabbott[m] has joined #fedora-coreos
copperi[m] has joined #fedora-coreos
ravanelli has joined #fedora-coreos
ravanelli has quit [Remote host closed the connection]
inflatador_ has joined #fedora-coreos
apollo13_ has joined #fedora-coreos
ebbex has joined #fedora-coreos
ikonia_ has joined #fedora-coreos
strigazi_ has joined #fedora-coreos
hjst has quit [*.net *.split]
apollo13 has quit [*.net *.split]
ebbex_ has quit [*.net *.split]
npcomp has quit [*.net *.split]
ikonia has quit [*.net *.split]
njha has quit [*.net *.split]
strigazi has quit [*.net *.split]
inflatador has quit [*.net *.split]
apollo13_ is now known as apollo13
njha has joined #fedora-coreos
hjst has joined #fedora-coreos
ikonia_ is now known as ikonia
ikonia_ has joined #fedora-coreos
npcomp has joined #fedora-coreos
Zork has quit [Quit: Client closed]
vgoyal has joined #fedora-coreos
nalind has joined #fedora-coreos
fifofonix has joined #fedora-coreos
<walters>
apollo13: In general I would try to use the new encapsulated containers for "primary" storage; then you can unencapsulate them to an archive repo to serve to pure-ostree clients - thinking of this "serving repo" like a cache (not a primary store). This is effectively how we're doing things for Fedora CoreOS today (except we put an .ociarchive file in s3 because we have disk images too, and those get versioned together).
<apollo13>
walters: but that will require a docker registry or are there other ways to store the .ociarchive?
<apollo13>
btw I rebuilt the image 2-3 times now and the diff shows that the kernel is always regenerated, is that by design?
<apollo13>
https://dpaste.org/VvLdT that is the diff I see with every build (~100 mb every time)
<walters>
ociarchive is a tarball which you can store however (including s3). But usually it's more ergonomic to run a registry
<apollo13>
and I can use ostree pull to pull the ociarchive?
<walters>
apollo13: In the rpm-ostree project we haven't pushed really strongly lately for bit-for-bit reproducibility; these things are usually bugs in other projects. It'd probably make sense to have a tracker though. the rpmdb.sqlite one e.g. is https://github.com/rpm-software-management/rpm/issues/2219
<apollo13>
or do I need to manually specify the archive somehow always
<walters>
I don't think it makes much sense to have clients pull .ociarchive files, that's quite inefficient
<apollo13>
me neither, the ostree stuff seemed the simplest
<apollo13>
are there any docs on how configuring a registry as remote look like?
<apollo13>
also will it use size_of(ociarchive) every time or does it deduplicate like I'd expect from layering?
<walters>
client only fetches layers which have changed.
<walters>
another way to say this is it will fetch exactly what podman/kube would fetch
<apollo13>
is there a way to configure an image to have that as an update source by default (sorry for the questions, it is hard to find all this)
<walters>
Or, really the simplest way to say it: We're aiming to make the host work the same way podman/kube does and needing to e.g. understand ostree is a bug
<apollo13>
walters: as for regenerating the initramfs, where would I report the bug there?
<walters>
rpm-ostree
michele_ is now known as michele
saschagrunert has quit [Read error: Connection reset by peer]
<apollo13>
walters: how can I tell coreos-assembler to deploy via container? manually update it in the file you said or is that a supported treefile option?
saschagrunert has joined #fedora-coreos
saschagrunert has quit [Remote host closed the connection]
<apollo13>
ah I can copy the config somewhere, let me try
saschagrunert has joined #fedora-coreos
saschagrunert has quit [Remote host closed the connection]
saschagrunert has joined #fedora-coreos
<apollo13>
mhm no, not sure how I can pass a custom configuration to create_disk.sh, I'll patch it for now
inflatador_ has left #fedora-coreos [#fedora-coreos]
jlebon has joined #fedora-coreos
<apollo13>
walters: so I managed to deploy an image from the container, where in the deployed system can I configure it to update from a docker registry?
ravanelli has joined #fedora-coreos
<guesswhat[m]>
Hey, anyone tried podman from testing-devel stream? Seems that podman.service can not start due to Error: mkdir /overlay: operation not permitted
mheon has joined #fedora-coreos
ravanelli has quit [Remote host closed the connection]
saschagrunert has quit [Remote host closed the connection]
saschagrunert has joined #fedora-coreos
baude has quit [Quit: Leaving]
<dustymabe>
guesswhat[m]: podman 4.4 just landed in testing devel at the end of last week. probably a regression, but our CI tests have passed. report an issue to the tracker and just make sure to note that it's against testing devel (and what version).
<apollo13>
okay, somehow the deployed image knows that it was deployed from a container:
<apollo13>
since it says Pulling manifest: ostree-unverified-image:oci-archive:/srv/builds/37.20230213.dev.3/x86_64/fedora-coreos-37.20230213.dev.3-ostree.x86_64.ociarchive
<apollo13>
guess if I manage to run create_disk with a proper path I am fine?
<apollo13>
ostree sign complains: "error: Requested signature type is not implemented" -- I create a ed25519 keypair with openssl and passed the b64 encoded key to sign, what else do I need to do?
<apollo13>
mhm, I might have the wrong "secret"
ravanelli has joined #fedora-coreos
<apollo13>
haha the ostree sign in the cosa container has no support for sign-ed25519, bugreport? if yes where
jpn has joined #fedora-coreos
plarsen has joined #fedora-coreos
jpn has quit [Ping timeout: 255 seconds]
<apollo13>
ok, so now I am able to sign commits but I am not yet sure how to sign the generated ociarchive
<apollo13>
any hints?
<apollo13>
(unless I unencapsulate, sign and reencapsulate?)
ravanelli has quit [Remote host closed the connection]
Kan-RuChen[m] has quit [Quit: You have been kicked for being idle]
<walters>
apollo13: as far as ed25519 yes...we never enabled that for Fedora, we probably could have, it just didn't come up. But obviously part of the idea of this container native flow is to use container-native signature models like sigstore
saschagrunert has quit [Remote host closed the connection]
plarsen has quit [Remote host closed the connection]
<apollo13>
walters: so using "ostree-image-signed:$imagereference" skopeo (or whatever) would natively check the sigstore/whatever signature? and yes container native would probably be fine, I never bothered with it till now. Guess I'll have to check what is easier
plarsen has joined #fedora-coreos
gursewak has joined #fedora-coreos
ravanelli has joined #fedora-coreos
ravanelli has quit [Remote host closed the connection]
ravanelli has joined #fedora-coreos
<apollo13>
and is there a location for ostree to put policy.json like it has for /etc/ostree/auth.json ?
<walters>
We should be honoring the stuff in /etc/containers by default, that's part of the idea here. (The reason for having a separate authfile is mentioned here https://github.com/containers/image/pull/1746 )
<apollo13>
if you ever make it to europe I will owe you a few beers
<apollo13>
you are like a walking search engine *gg*
<walters>
Unfortunately I'm good at that and not at writing docs
<apollo13>
sounds familiar, though I guess being a coreos engineer also helps in knowing where to look :)
ravanelli has quit [Remote host closed the connection]
<apollo13>
walters: looking at your bootc demo images. I am wondering how I would get a disk image (qemu?) to write to disk and how they are supposed to be configured if ignition is removed
<apollo13>
having to run podman there to install the image seems hard :D
<walters>
Persistent config can also be injected directly into /etc and /var post-install
<walters>
But the lack of "day 2" management for these things is too problematic; configmaps and derivation are better.
<apollo13>
mhm no, I literally mean "how to get this image onto my hypervisor disk in the first place"
<apollo13>
or do I completly missunderstand the point of those images
<apollo13>
(or even easier: I want deploy this on a bare metal server)
bgilbert has joined #fedora-coreos
<walters>
Ultimately it's going to be more useful for me to document this stuff than to answer here 😄 But the short answer is bootc install can be run from any live environment
<apollo13>
haha, fair point. okay, so my options are: cosa which can do quite a few things, raw rpm-ostree like silverblue or bootc which is "experimental" and requires me to boot the machine to install something
<baude>
bgilbert, fyi made great progress over weekend ... so you should start to see PRs flow; and more specific questions like the one above to move from hack/poc to something real
<bgilbert>
+1
<bgilbert>
I don't know the answer wrt openshift/release. what are you trying to accomplish?
<baude>
any ideas on why my buildextend-hyperv is not showing up in cosa shell? i did use COREOS_ASSEMBLER_GIT
<dustymabe>
baude: maybe you forgot to recompile `cosa` OR you're not using the newly compiled `cosa` binary inside the container?
<baude>
silly me, thouight building on the host would give me the goods
<baude>
so in the container, i have to build and install yes?
<dustymabe>
you just have to get the new binary into your $PATH
apollo13[m] has joined #fedora-coreos
<dustymabe>
you can add a `-v $COREOS_ASSEMBLER_GIT/bin/:/usr/local/sbin/:ro` to your cosa alias/function
<dustymabe>
which should give preference to what is in /usr/local/sbin/
nalind has quit [Quit: bye for now]
jpn has joined #fedora-coreos
jpn has quit [Ping timeout: 260 seconds]
<bgilbert>
baude: I applaud your extracting the KVP code into a helper package
<bgilbert>
I'll review it as part of the Ignition PR review
cyberpear has quit [Quit: Connection closed for inactivity]
<bgilbert>
baude: let's refactor this so the guest side of libhvee has a generic KVP implementation, and the Ignition bits are in the Ignition codebase
<bgilbert>
baude: the parts that can only be useful from Ignition should just be in Ignition
Turnikov has joined #fedora-coreos
<baude>
lol which would be none of it
<baude>
so you are thinking about the com.coreos.ignition._ stuff maybe ?
<baude>
if so, yeah, i can even start making those changes
<baude>
bgilbert, btw, libhvee is like 6 hours old, so we are still refactoring quite a bit underneath ... which probably even lends itself to your suggestion more!