ravanell_ has quit [Remote host closed the connection]
ravanelli has joined #fedora-coreos
ikonia_ has quit [Ping timeout: 255 seconds]
ikonia_ has joined #fedora-coreos
fifofonix has joined #fedora-coreos
fifofonix has quit [Ping timeout: 255 seconds]
vgoyal has joined #fedora-coreos
jpn has quit [Ping timeout: 246 seconds]
nalind has joined #fedora-coreos
plarsen has joined #fedora-coreos
ravanell_ has joined #fedora-coreos
ravanelli has quit [Ping timeout: 252 seconds]
jpn has joined #fedora-coreos
jpn has quit [Ping timeout: 255 seconds]
jlebon has joined #fedora-coreos
baude has joined #fedora-coreos
jpn has joined #fedora-coreos
ravanell_ has quit [Remote host closed the connection]
<baude>
i know bgilbert does not come around for a while yet, but i was curious if others might know how I can write some files to the real rootfs from ignition itself. I do not mean from its config. I mean content from the binary ignition itself.
<dustymabe>
baude: the Ignition files stage writes files into the real rootfs so maybe look to that area for an example?
<jlebon>
baude: how you'd normally do it in golang. :) the only special thing is you'd prefix the path with s.DestDir. see e.g. the code that writes systemd presets
<dustymabe>
listen to jlebon
<jlebon>
i guess there's also the logging bit. grep for `s.Logger.LogOp`
<SumantroMukherje>
would be great to have them reviewed
<SumantroMukherje>
and then we can publish them to the test day app
<walters>
jlebon: sure
<baude>
jlebon, wfym there is also the logging bits ... are you suggesting that i should log the writes as well ?
<baude>
or do both ... inside the logop func
saschagrunert has quit [Remote host closed the connection]
bgilbert has joined #fedora-coreos
Betal has joined #fedora-coreos
<jlebon>
baude: yeah, ignition usually logs the writes it does to the rootfs. but i guess it depends on what you're doing. if it's some deep implementation detail, maybe it doesn't make sense
<jlebon>
e.g. if it's just a temporary file to then run some cmd in the rootfs
<baude>
hey bgilbert i was asking earlier but am not quite understanding; are you up for helping me get the hyperv pr across the finish line? I think at this point, I just need to learn to do the writing to the rootfs
jpn has quit [Ping timeout: 255 seconds]
<baude>
do i do that in internal/providers/hyperv?
<bgilbert>
baude: in meetings for a bit, will ping later
jpn has joined #fedora-coreos
fifofonix has quit [Read error: Connection reset by peer]
jpn has quit [Ping timeout: 255 seconds]
<bgilbert>
baude: I'm around now
<bgilbert>
baude: this change will require some plumbing, since we haven't had this problem before
<bgilbert>
looking
<bgilbert>
baude: fetchProviderConfig() in engine.go will need to plumb `e.State` into the fetch function
<bgilbert>
baude: which means all the fetch functions will need to have an argument added
<bgilbert>
baude: then the State struct will need a field (or fields) added for whatever data needs to be stored
<bgilbert>
baude: and then in files.go, runImpl() will need to call a new function that reads the data back out of the state struct and writes the files to disk
<bgilbert>
the writing-out-files part should be conditional on the platform ID. we could make a whole API abstraction for it, but tbh the files stage should probably just call directly into the Azure provider to do the writing
<bgilbert>
Hyper-V, not Azure
<bgilbert>
eh
<bgilbert>
maybe it'd make sense to have a generic API callback, actually. otherwise passing the state struct to the fetcher doesn't really make sense in general
<baude>
bgilbert, is this something I should skip for now and you guys do given it is going to require plumbing?
<bgilbert>
baude: was just thinking about that. I can probably just go ahead and do the plumbing; there's not a lot