<dustymabe>
darknao: is your setup easy enough to reproduce? i.e. if we wanted to test a theory (usually stuff like this is new kernel related) could we give you instructions and you run the test?
jpn has joined #fedora-coreos
<darknao>
well, I was about to spin up a new test vm with an OSD on it so I could try the testing/next release and see if there is any improvment
<dustymabe>
sweet - yeah that will be good data
<dustymabe>
the other test I want you to run is overriding the kernel in `37.20230110.3.1` to be the old kernel from `37.20230110.3.1`
apiaseck has quit [Read error: Connection reset by peer]
Betal has joined #fedora-coreos
fifofonix has joined #fedora-coreos
jpn has quit [Ping timeout: 255 seconds]
jpn has joined #fedora-coreos
<jlebon>
ravanelli: found another issue in the testiso PR. testing a patch then will push it up. :)
<jlebon>
dustymabe: thoughts on folding your commits in https://github.com/coreos/coreos-assembler/pull/3298/commits into the main "kola: Refactor testiso tests" commit? planning to fold mine as well since they're mostly minor tweaks to the main change
jpn has quit [Ping timeout: 246 seconds]
Turnikov has quit [Ping timeout: 248 seconds]
shoragan has quit [Read error: Connection reset by peer]
jpn has joined #fedora-coreos
shoragan has joined #fedora-coreos
jpn has quit [Ping timeout: 248 seconds]
<dustymabe>
jlebon: yeah I don't care
<dustymabe>
go for it
<jlebon>
ok done :)
jlebon has quit [Remote host closed the connection]
<ravanelli>
jlebon: Thanks for checking/finding it ;)
jpn has joined #fedora-coreos
bgilbert has joined #fedora-coreos
jpn has quit [Ping timeout: 248 seconds]
<baude>
hello bgilbert i was hoping you could answer a few questions for me wrt ignition if you have a minuteS?
<bgilbert>
baude: sure
<baude>
just to level set, I am interested in seeing ignition "work" with hyperv
<baude>
i assume it isat least two things: teach ignition to recognize it is in hyperv AND teach it what to do when it is
<bgilbert>
well, one thing. Ignition doesn't try to autodetect platforms because that has security implications. it depends on being booted with an ignition.platform.id=<identifier> kernel argument
<bgilbert>
FCOS and RHCOS build separate images for each platform with the correct kernel argument set
<baude>
ok ok
<bgilbert>
so yes, Ignition itself just needs to learn how to fetch userdata
<baude>
ok
<baude>
do you have ideas on how you want that done?
<bgilbert>
the more annoying part is all of the plumbing needed to make FCOS/RHCOS images for the new format
<baude>
or is that open for debate
<bgilbert>
because it touches many repos
<bgilbert>
baude: I don't know HyperV. is there a userdata mechanism?
<baude>
understood
<baude>
im actively trying to determine that ... ofc this is not my sweet spot, so i may be not looking for exactly the right terms
<bgilbert>
we've found that cloud platforms almost always support userdata and local hypervisors almost always... don't
<bgilbert>
so we have to hack something up
<baude>
hahahah
<bgilbert>
VMware and VirtualBox have guest variables that we can make work, qemu has fw_cfg which isn't meant for this either
<bgilbert>
basically we need a way for the host to set something that can be read from the guest
<baude>
yup
<baude>
do any of these use cdrom media for this?
<bgilbert>
we have reluctantly supported it in some cases, but it's a last resort
<bgilbert>
those cases being: where it's the API specified by the platform, like Azure and OpenStack
<bgilbert>
the reason is
<bgilbert>
if the CD doesn't show up, is that because there's no userdata (so we should continue) or because we're still detecting hardware (so we shouldn't)?
<bgilbert>
timeouts are subject to false negatives
<baude>
understood, i have experience with cloud-init upstream
<bgilbert>
hah. yeah
<baude>
im googling on the topic and i also asked a windows engineering group i happen to follow
<bgilbert>
HV_KVP_EXCHANGE_MAX_VALUE_SIZE in <linux/hyperv.h> is 2048, but it's not clear to me whether that's an arbitrary limit or whether the protocol actually supports larger
<bgilbert>
2048 would be the lowest limit in any platform we support, but it's large enough to be workable
<bgilbert>
e.g. the AWS limit is 16k
<baude>
yeah, im struggling with how the key/value gets *set* in the windows host
<bgilbert>
because Ignition supports config merge/replace directives that give URLs to other configs
<baude>
and they fiddle with the registry evidently
<bgilbert>
the fact that stuff goes in the registry isn't inherently scary, I think. it's a database
<bgilbert>
I'd expect that these would go into a key for the particular VM
<bgilbert>
wait, does it use the registry? that might just be on Windows guests
<baude>
the powershell fragments done seem to work
<bgilbert>
do or don't?
<baude>
dont
<bgilbert>
oh, how so?
<baude>
i dunno .... i am a windows spazz
<bgilbert>
my current sense is that this is the way. we'd need to
<bgilbert>
1) verify that we can set a property and have hv_kvp_daemon pick it up
<bgilbert>
2) stop hv_kvp_daemon, delete its data files, restart it, and verify that the property is restored
<bgilbert>
(i.e. that the props are re-sent on every new host-guest connection)
<baude>
lol, i tried to start the kvp daemon in fedora and it just hung
<baude>
good stuff
<bgilbert>
I suppose this is used on Linux by approximately no one :-(
<bgilbert>
3) figure out the timeout issue. it's unavoidable here but we can probably set a reasonably short one, if the property doesn't come in with the initial burst
<bgilbert>
4) write Ignition code
<bgilbert>
we might not get past 1 of course
<baude>
im working on 1
<baude>
so i can see pool 3 and it def has content
<bgilbert>
we don't currently have plans to prioritize this work from the CoreOS side (that'd have to be an internal discussion) but PRs would be very welcome
<bgilbert>
baude: thanks for pursuing this! feel free to ping with any questions / followup discussion