<travier[m]>
Heads up, I incorrectly marked some tests as platform independent when they not have been so made https://github.com/coreos/fedora-coreos-config/pull/2212 to fix it. In case your seeing new test failures on AWS or similar
<travier[m]>
* Heads up, I incorrectly marked some tests as platform independent when they should not have, so made https://github.com/coreos/fedora-coreos-config/pull/2212 to fix it. In case your seeing new test failures on AWS or similar
<travier[m]>
* Heads up, I incorrectly marked some tests as platform independent when they should not, so made https://github.com/coreos/fedora-coreos-config/pull/2212 to fix it. In case your seeing new test failures on AWS or similar
jpn has quit [Ping timeout: 248 seconds]
jpn has joined #fedora-coreos
jcajka has joined #fedora-coreos
vgoyal has joined #fedora-coreos
nalind has joined #fedora-coreos
mheon has joined #fedora-coreos
jlebon has joined #fedora-coreos
saschagrunert has quit [Remote host closed the connection]
<baude>
dustymabe, travier[m] walters on the topic of hyperv, I theoretically have this working now with ignition ... but, there is one detail I need to account for and I want to make sure it won't deter you folks from accepting it
<baude>
on this topic, can you speak for ignition ?
<baude>
i mean generally
<dustymabe>
baude: generally yes, authoritatively no
<baude>
ok ok
<baude>
i just dont want to waste time, allow me to elaborate
<dustymabe>
obviously waiting around for bgilbert and/or spresti[m] would be more useful
<baude>
when bgilbert and i spoke last, we looked at ignition enablement through what microsoft calls WMI KVP (key value pairs)
<baude>
it is basically a mechanism to inject data into the virtual machine
<baude>
one problem with this is the value side is limited to 2k; and because windows utf, it really ends up being 1k
<baude>
in looking at a base ignition file from podman machine, that file size is closer to 6kl
<baude>
6k
<dustymabe>
baude: I assume you guys are compressing where possible already?
<baude>
elaborate please
<dustymabe>
ignition supports compression in fields
<dustymabe>
butane will opportunistically compress things for you
Turnikov has joined #fedora-coreos
<baude>
butane run on windows?
<dustymabe>
in a container maybe
<baude>
how can i run a container when what we are doing is setting up the ability to run a container
<dustymabe>
i think the point is that it's possible and if you want to see it in action you can try it with butane
<baude>
ok ok
<dustymabe>
butane is just golang
<baude>
dustymabe, ok, and that also assumes the compressed result will always be less than 1k
<dustymabe>
right, that's the other half
<baude>
we could also gz the file itself, but that has the same assumption
<dustymabe>
how efficient will it compress the 6k? I don't know
<baude>
so slice and reassemble is sort of the next idea ... you'd have a control file with a sha, and then reassemble in the vm and verify things match
<baude>
dustymabe, gzip'd default machine file is still over 1k
<walters>
one option is having the base ignition config fetch the rest over https from the host
<dustymabe>
yep, unfortunately that requires more setup and pieces to manage
<jlebon>
we have size restrictions on other platforms, but none i think as restrictive
<jlebon>
another thing worth investigating is injecting the ignition config into the image. that'd require some bit fiddling on podman's part similar to what coreos-installer does
<walters>
the problem is that writing ext4 when you're not the linux kernel is painful
<baude>
on the size thing, interestingly Linus set the size in Linux to be 4k, but it is MS WMI that sets it on the host, and it is 2048
<baude>
yah
<walters>
generalizing the ISO injection by having a dedicated partition would be easier for external tools, although even then writing to qcow2 is still going to be hard without also shipping other tools
<jlebon>
it wouldn't be filesystem aware, but offset and span level
<walters>
hmmm, I could imagine having a dedicated sparse file for this would work - it's actually the same problem domain as grubenv
<jlebon>
we can verify on the build side that the file spans contiguous blocks and annotate... somewhere the offset
<dustymabe>
let's grab some time together with bgilbert to discuss?
<dustymabe>
I'd like to keep the non podman-machine use case in mind
<baude>
ok, when this was discussed earlier, he did not care for this idea
<baude>
but given what we know today, mayube it is the easier path
<travier[m]>
dustymabe: oh ,thanks for catching that :/
<baude>
dustymabe, i dont think podman or not is applicable here
<baude>
it is the hypervisor with the limitation
<baude>
and btw, the apple hypervisor is going to be next and likely has even worse
<baude>
so the file offset idea might be applicable to a broader group as well
<dustymabe>
baude: I understand, but I think the solution shouldn't be too hard for a user to execute who just wants to spin up FCOS with their own ignition without podman-machine
<baude>
uh
<dustymabe>
there is a subtle difference there, but there is a difference
<baude>
you guys can write an exe for this ? lol
<dustymabe>
doubtful, but we will provide docs
<walters>
this all said in the general case, one can take a libguestfs-style approach of booting the kernel directly with a small custom userspace dedicated to writing files
<dustymabe>
jlebon: for https://github.com/coreos/fedora-coreos-config/pull/2210#issuecomment-1414238510 the commit message is actually accurate - it's just not super clear because it's an indirect relationship. I'll try to update the commit message to be more clear and then hopefully we can merge without a new full CI run.