<apollo13>
hi there, I am playing around with coreos assembler and trying to build custom ostree remotes. Now cosa build seems to generate an ociarchive, how can I import that into an ostree repo?
<apollo13>
or are container registries supposed to be the new update path :D
<apollo13>
okay looks like I am getting somewhere with unencapsulate, but does that work via a file as well?
<apollo13>
oh ociarchive prefix, so then I can unencapsulate that into a new repo and pull it into an archive mode one?
Turnikov has joined #fedora-coreos
jpn has joined #fedora-coreos
saschagrunert has quit [Remote host closed the connection]
vgoyal has joined #fedora-coreos
ravanelli has joined #fedora-coreos
ravanelli has quit [Remote host closed the connection]
ravanelli has joined #fedora-coreos
ravanelli has quit [Remote host closed the connection]
ravanelli has joined #fedora-coreos
Turnikov has quit [Ping timeout: 268 seconds]
Turnikov has joined #fedora-coreos
<walters>
apollo13: yes
<walters>
but also, indeed the whole direction is to move to registries for updates
cybercrypto has joined #fedora-coreos
Turnikov has quit [Ping timeout: 268 seconds]
Turnikov has joined #fedora-coreos
mheon has joined #fedora-coreos
<apollo13>
walters: but as far as I can tell it is not really there is it? or differently put: would you advise me to run solely from registries as off now (if that is even possible)
<walters>
The desktop system I'm talking to you from is derived from the fedora silverblue base image this way
<walters>
every OpenShift 4.12 node updates this way
<walters>
Now we're really in some ways just 1/3 of the way through this journey...a ton more to do
<apollo13>
ok, another question that popped into my mind. I am currently "forking" (or rather using fedora-coreos-config) as submodule to add nomad etc into a "respin" of mine so to say
nalind has joined #fedora-coreos
<apollo13>
and then I thought about another variant that would add some other tooling
<apollo13>
can I have a base compose so to say where the other two variants base on
<apollo13>
or will those have to be fully different systems
<apollo13>
differently put: if I use rpm normally I know I can install nomad on one server and httpd on another and they would still be able to efficiently share all the base RPMs from one repo
<apollo13>
how does this work with ostree remotes?
jlebon has joined #fedora-coreos
<apollo13>
I mean with the docker workflow from https://coreos.github.io/rpm-ostree/container/ it is clear. I'd have my own base image and the extra software would be two different layers with the base layers as parent
<apollo13>
but I currently don't understand if or how I would do this with cosa (or am I overthinking it and running cosa build will already reassmble completely the same on two machines)
<walters>
it actually will likely share some layers due to the way "chunking" is implemented
<walters>
Using a Dockerfile (or any equivalent container-native build system) will indeed create clearly distinct layers (usually, though there is the option of squashing, which will actually I think today break things)
<walters>
Now, what we will have at some point in the future is the rpm-ostree compose image --from equivalent that declaratively and intelligently generates derived images
<apollo13>
mhm okay, but assume I take the fedora-coreos-config repo and add a branch which adds one extra package. Then I build a ostree commit out of the stable branch today and tomorrow I build my branch. will the two commits after importing into an archive mode ostree repo reuses 99% of the storage there?
<walters>
yes
<apollo13>
that is assuming the rpm post install scripts don't do anything nasty I assume?
<walters>
Yes...though it'd have to be nearly a malicious script to cause problems
<apollo13>
probably, but I am merely trying to understand the failure potential. So a post-install script writing the current time into a file would be enough (or is the time frozen, which I guess it might be)
<apollo13>
A treefile always starts from scratch right? Like I cannot tell it something along the lines of "use this ref of fedora core os" and now add my rpms and commit this as new ref (like you'd do in a Containerfile with FROM and then RUN)
jcajka has quit [Quit: Leaving]
<walters>
Right, it always builds a base image today, that's what I meant above with wanting compose image --from
<apollo13>
understood, sorry it is still pretty much to take in and understand
<apollo13>
I was happy enough to be able to actually built core os today after I figured out the unencapsulate stuff :)
<walters>
Yeah, we're in a process of trying to rework everything in a container-native way, but while also supporting our existing flows and having a seamless transition
<walters>
Yeah, coreos-assembler is doing some other stuff on top; the main operative thing here is the non-RPM content. But other things shipped in Fedora don't use coreos-assembler (silverblue and IoT). I also started https://github.com/cgwalters/bootc-demo-base-images as a smaller base image that is also directly built (and build-able) with rpm-ostree compose image, no cosa involved
<jlebon>
you can mount the source into a container
<dustymabe>
yeah, mount the source dir into the container (see the alias at the link above)
<baude>
i use the alias too
<dustymabe>
did you define `COREOS_ASSEMBLER_GIT` env var?
<dustymabe>
when you do that it mounts in your host dir read-only into the container
<baude>
god help me
<baude>
roger
<walters>
I install and test/use cosa in my toolbox container which also has my IDE
<baude>
is coreos_assembler_git a fully qualified path ?
<jlebon>
baude: safer to assume so
<jlebon>
walters: yeah, same here
<baude>
walters, bye ide you mean your super emacs setup ?
<baude>
can cosa spit out a vpc or do you use qemu-img for that?
<dustymabe>
vpc? you mean vhd?
<baude>
yes
<jlebon>
cosa uses qemu-img :)
<jlebon>
that file i linked to is more or less a wrapper around `qemu-img convert`
<baude>
ok, i figured so given the -o
<baude>
dustymabe, in the override path you provided, `overrides/rootfs/usr/lib/dracut/modules.d/30ignition/ignition` is ignition there the binary itself or another dir?
<dustymabe>
it's the binary
<baude>
kk and last question , maybe ?, it looks like i need to make a src/cmd-buildextend-hyperv
<baude>
but looking at the azure one, i dont think we need any of that special sauce?\
<baude>
jlebon, dustymabe ok i have myself turned around here ... i made my changes to cosa ... do you then run cosa shell and call things from inside that?
<baude>
apparently yes?
<walters>
yeah
<dustymabe>
baude: yes, that works - i can screenshare with you if you'd like some more guidance
<baude>
i have it working now i guess but i am hitting another problem, maybe you or walters knows
<baude>
it looks like hyperv gen2 requires vhdx
<baude>
i think that is more than just a different file extension name
<dustymabe>
baude: yeah, that would require some investigation
<baude>
im doing it now but it is from ground up
<dustymabe>
not sure if bgilbert has any prior knowledge here
<dustymabe>
ravanelli: when looking at this different between say the 4.12 backport and the main branch PR I see some differences that aren't clear to me why they are different
daMaestro has quit [Quit: Leaving]
<dustymabe>
nvm - i was looking at an older version of the code
<baude>
bgilbert, did you happen to see which hv module creates /dev/vmbus/hv_kvp?
<baude>
my best guess is hv_kvp
<baude>
dustymabe, jlebon is it possible in cosa to add a kernel module to the initrd?
<dustymabe>
baude: I assume it's a kernel module that's already provided by the kernel RPMs (i.e. it's in the realroot you just need it in the initrd)?
<baude>
ya
<dustymabe>
baude: you'd modify the ignition dracut module to add it
<dustymabe>
been a long time since i've done it though - so might be some caveats
<dustymabe>
try it out :)
<baude>
what you sent me is in fedora-coreos-config not ignition, correct?
<dustymabe>
right. it was an example of what you'd need to add to the module-setup.sh from ignition.. if you just want to hack then just open that overlay.d/05core/usr/lib/dracut/modules.d/40ignition-ostree/module-setup.sh in the local git checkout and your module next to the zram one
<dustymabe>
but when this gets PRd it would need to go in the module-setup from the Ignition repo I think
<baude>
yeah
<dustymabe>
i'm going to head out - have a good rest of your day baude
<baude>
dustymabe, tyvm! have a gr eat weekend
jpn has joined #fedora-coreos
jpn has quit [Ping timeout: 248 seconds]
jpn has joined #fedora-coreos
jlebon has quit [Quit: leaving]
jpn has quit [Ping timeout: 252 seconds]
daMaestro has quit [Quit: Leaving]
mheon has quit [Ping timeout: 260 seconds]
jpn has joined #fedora-coreos
jpn has quit [Ping timeout: 260 seconds]
fifofonix has joined #fedora-coreos
jpn has joined #fedora-coreos
fifofonix has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]