<bgilbert>
baude: I'm here now, if you're still around
<baude>
bgilbert, ok, circling back ... i have an ignition binary i want to try
<baude>
do you have a recommendation on how I could do such a thing?
<baude>
should i be using cosa to make a qcow2 and somehow inject my binary in?
<bgilbert>
...oof. there's the easy way and the hard way
<baude>
im listening
<bgilbert>
the easy way is to launch pretty much any Linux in Hyper-V, sftp in the binary, and run it
<bgilbert>
you only really need to run the fetch stage
<bgilbert>
if it fetches a valid config, there's no real need to demonstrate that Ignition can actually write files or partition disks
<baude>
does ignition have something of a sub-command called fetch ?
<bgilbert>
since that stuff isn't platform-specific
<bgilbert>
Ignition runs in stages, which are separate invocations from separate systemd units
<bgilbert>
because the OS needs to sequence other actions between those stages
<bgilbert>
so something like `ignition -platform hyperv -stage fetch -config-cache cache.ign`
<bgilbert>
and probably -log-to-stdout
ravanelli has quit [Remote host closed the connection]
<baude>
ok ok
<bgilbert>
but eventually you'll need to do an all-up test in a real OS image
<bgilbert>
and there, yes, you'd inject your build into cosa
<baude>
would it have to be in rpm form ?
<bgilbert>
if ~/cosa is your cosa build root, you'd do `make install DESTDIR=~/cosa/overrides/rootfs`
<bgilbert>
from the root of the Ignition source
<baude>
tyvm
<baude>
ok couple more quick quiestions
<bgilbert>
one other thing
<baude>
k
<bgilbert>
you'll need the image to have the correct ignition.platform.id= kernel argument
<bgilbert>
(`hyperv`)
<baude>
fsck
<baude>
ok
<baude>
hows that get done with cosa ?
<baude>
in the easy way, im assuming you say just edit grub for now
<bgilbert>
hacky option: manually modify the BLS config file in /boot/loader using guestfish, then qemu-img convert to a VHDX
<bgilbert>
right
<baude>
kk
<baude>
ok my turn
<bgilbert>
real implementation: add a buildextend-hyperv command
<bgilbert>
which is just a symlink and a few lines of patch IIRC
<bgilbert>
we'll need to eventually do that anyway, so if you feel like doing it, PRs definitely welcome :-)
<baude>
to add a platform, do i just need to add a configs.Register in internal/platform/platform.go ?
<bgilbert>
I believe so, yeah
<baude>
i dodnt see anything more that would be obvious
<baude>
ok, so theoretically this should all work
<bgilbert>
+1
<baude>
given i have already mock tested all of this
<baude>
oh oh
<baude>
side question .... s you were emphatic about the no daemon funnibusiness
<baude>
one thing giuseppe and i learned when dealing with the kernel device and its stupid protocol is that once you read, the kvps are gone (until reboot)
<bgilbert>
...that's what I was afraid of
<baude>
so
<baude>
that kind of sucks
<baude>
and because that pool is one way, we can not read and put it right back either
<bgilbert>
presumably it's not "gone", it's just that the host doesn't think it needs to send the keys again
<bgilbert>
unless something changes
<baude>
right
<baude>
i can look to see if the host can be told resend those bad boys
<bgilbert>
that would be ideal
<baude>
if that is the case, we could wire that up
<bgilbert>
there's another approach, of course, but it feels bad
<bgilbert>
which is that we write out the pools ourselves. we know the on-disk format.
<baude>
we could also write the pools
<bgilbert>
yup
<baude>
yup
<bgilbert>
:-)
<baude>
it seems like maybe that would be the rightthing TM until someone says otherwise?
<baude>
but maybe don't put them in the same spot?
<bgilbert>
we have to put them in the same spot or there's no point
<baude>
or namespace them in the same spot with a dir
<bgilbert>
that's where anything in the real root will be looking for them
<baude>
fair enuf
<bgilbert>
of course, then that app might think the daemon is running when it isn't
<bgilbert>
ohh
<bgilbert>
even worse: the real root won't even be mounted when we do the fetch
<baude>
right,t hat was my concern
<baude>
however, if we tell the host to requeue the kvps
<bgilbert>
indeed
<bgilbert>
if there's a way to requeue, we should 100% use it
<baude>
and then the daemon was there, it would obviously work
<baude>
which leads me to the next logical question ...
<baude>
should we handle the case where the daemon is actually there just in case
<baude>
as like ... a fallback
<bgilbert>
in the initrd?
<baude>
i mean i dont want to , but if i am gong to made to do it, id rather account for it now
<bgilbert>
IMO no. random stuff doesn't usually get run in the initrd, and I'm not aware of any use case for it
<bgilbert>
we can file a bug saying that this is a known issue
<bgilbert>
but we shouldn't implement a thing that will likely never be needed, and thus never actually tested
<baude>
or we could forget i mentioned it and say a little extra somoething on Sundays
<bgilbert>
also works
<baude>
ok, i will report back tomorrow
<bgilbert>
if we're going to write out the pools
<baude>
yeah ?
<bgilbert>
see state.go. there's a way to pass information between Ignition stages
<bgilbert>
so basically fetch would store the KVs in the state struct, then we'd have to patch the files stage to notice them there and write out the pools
<bgilbert>
once the root filesystem is mounted
<baude>
bc you dont want to write to the filesystem in the initrd?
<bgilbert>
writing to the FS in the initrd doesn't do any good; they have to end up in the real root or it doesn't serve a purpose
<baude>
right
<baude>
im just verifying why
<bgilbert>
yup
<bgilbert>
I think the handoff is straightforward to do; I just don't like the brittleness
<bgilbert>
reimplementing some other random software's output format
<baude>
well it starts with a shit protocol
<bgilbert>
yeah
<baude>
and gets smellier
<baude>
and that, we did not make up
<bgilbert>
only other option I see is to require the actual daemon to run in the initrd, but then we'd still need to pass the state to the real root
<bgilbert>
so I think let's do the state handoff inside Ignition for now
<bgilbert>
rather than using the daemon
<bgilbert>
and see where that gets us
<baude>
right, but that daemon remember comes with a license
<bgilbert>
yeah, the alternative proposal would be that Ignition requires the daemon to be installed separately, and running
<bgilbert>
which would require the OS vendor to arrange that
<bgilbert>
feels worse
jpn has joined #fedora-coreos
<baude>
ok
<baude>
its already a bloodbath
<bgilbert>
yes it is
<bgilbert>
sure would have been nice if they'd used one file per key, etc., rather than inventing some binary thing
<bgilbert>
okay, sounds like we have a path
<baude>
i mean, you guys really got a gift when this idiot volunteered to help