<ravanelli>
We are having the Fedora 38 meeting now to enumerate new test cases
jpn has quit [Ping timeout: 255 seconds]
gursewak has quit [Ping timeout: 246 seconds]
baude has joined #fedora-coreos
<baude>
heya bgilbert
<baude>
id like to catch up a little re: hyperv
* bgilbert
waves
<bgilbert>
how's things?
<baude>
did you leave the frozen tundra ?
<bgilbert>
yeah
<bgilbert>
back in the city and it's warm outside
<baude>
cool ... ok ... ive got a curveball on the kvps
<baude>
i dont think hyperv has standard socket connections
<baude>
so vsock is encouraged
<bgilbert>
for host-guest communication, you mean?
<baude>
yeah, we use it to notify the os is booted
<baude>
the problem is ... iiuc vsock would require that the guesty know the vm "id" and port number to connect to
<bgilbert>
hmm, you can't just have a TCP listener on the host?
<baude>
i try to assume noth8ing about tcp on peoples hosts
<baude>
but would the guest not still need to know *something* to make that connection ?
<bgilbert>
sure, but that's why we have Ignition :-)
<baude>
yes yes, and that is option 1 or 2 depending on how we look at things
<bgilbert>
go on
<baude>
all i am saying is ... this whole discussion makes me start thinking about the decision to not write the kvps
<bgilbert>
to /var, you mean?
<baude>
and the beautiful design ms made where once read, those kvps are gone gone until reboot
<baude>
yeah
<bgilbert>
there was no such decision on my end. :-) I've been assuming we'll need to do that
<baude>
oh sure ... play Sgt Schultz!
<bgilbert>
¯\_(ツ)_/¯
<baude>
how big of a pita is it to write to the real /var from the initrd ?
<bgilbert>
not very
<baude>
ok, it is probably worth it then
<bgilbert>
there's a state-passing mechanism between Ignition stages
<bgilbert>
the info would be put in the state struct, automatically serialized out, and then the Ignition files stage would read the state and write the files
<baude>
maybe tomorrow I will come back then and poke for an example
<bgilbert>
+1
<bgilbert>
also, when you get a chance, there are outstanding review comments on at least a couple of the hyperv PRs, including the Ignition one
<baude>
ok, otherwise, libhvee is looking better and we have begun releasing versions
<bgilbert>
hopefully its API isn't being considered stable yet?
<baude>
oh, i know about the ignition one, didnt know the others had some too ... i have the libhvee fixes in a branch, need to push it and that will put the ignition pr in good shape
<baude>
btw, i dont see any api related comments on the ignition pr itself ... i think we are in good shape once i make changes
<baude>
u dead sure on that suffix comment?
<bgilbert>
I'll give the Ignition PR another look once you get those changes up. there were some existing comments I don't think we 100% came to agreement on, which is why I was asking about APIs
<baude>
oh ok
<bgilbert>
re the suffix comment, yes
<baude>
yeah, ill let you know once i push ... after tomorrow i will have more time
<bgilbert>
+1, thanks!
<baude>
well, im getting the right suffix , mayube i have a change here locally
<bgilbert>
I mean, yeah, the code will work, but it's going behind the back of existing infrastructure
<bgilbert>
and it doesn't need to at all
<bgilbert>
I think the incorrect suffix causes problems somewhere else, but I don't recall offhand