michele has quit [Remote host closed the connection]
michele has joined #fedora-coreos
daMaestro has joined #fedora-coreos
chrish136 has quit [Quit: WeeChat 3.6]
sentenza has quit [Remote host closed the connection]
gursewak has quit [Quit: Leaving]
saschagrunert has joined #fedora-coreos
jcajka has joined #fedora-coreos
daMaestro has quit [Quit: Leaving]
hotbox has joined #fedora-coreos
jpn has joined #fedora-coreos
jpn has quit [Ping timeout: 240 seconds]
Betal has quit [Quit: WeeChat 3.8]
<travier[m]>
michele: We try to alawys land things in testing first and for some major vulnerabilities we shortened the time between the fix landing in testing and in a stable release.
jpn has joined #fedora-coreos
cosmic-equation[ has quit [Remote host closed the connection]
jpn has quit [Ping timeout: 250 seconds]
jpn has joined #fedora-coreos
bowsers has quit [Quit: Client closed]
ravanelli has joined #fedora-coreos
ravanelli has quit [Remote host closed the connection]
darknao_ is now known as darknao
peko[m] has quit [Excess Flood]
jpn has quit [Ping timeout: 246 seconds]
jpn has joined #fedora-coreos
nalind has joined #fedora-coreos
jpn has quit [Ping timeout: 240 seconds]
mheon has joined #fedora-coreos
plarsen has joined #fedora-coreos
baude has joined #fedora-coreos
jpn has joined #fedora-coreos
jpn has quit [Ping timeout: 268 seconds]
spresti has joined #fedora-coreos
jpn has joined #fedora-coreos
<baude>
hey folks, my understanding is that ignition does have a series of default locations where it looks for its configuration file, but those are locations in the filesystem? is that correct?
ebbex has joined #fedora-coreos
baude has quit [Read error: Connection reset by peer]
<dustymabe>
baude: IIRC if it finds a file at /boot/ignition it will use that
<dustymabe>
baude: IIRC if it finds a file at /boot/ignition/config.ign
<dustymabe>
it will use that
<dustymabe>
but I don't think that's necessarily external API (meaning not sure if we guarantee to support that in the future) cc spresti
<bgilbert>
dustymabe: that's external API, yeah
<baude>
dustymabe: bgilbert have you ever considered a default http location?
<bgilbert>
baude: absolutely not
<baude>
why not
<bgilbert>
what could it possibly be that wouldn't create a security hole?
<baude>
in the case of vms, if the default location was an internal bridged network, whats the hole?
<baude>
is it ignitions'
<baude>
role to worry about that stuff?
<baude>
bgilbert: i am still looking for a way to getg igition working on the applehv
<bgilbert>
is it Ignition's role to worry about whether it's fetching a config, which can fully compromise the system if it wants, from an unauthorized location? yes.
<baude>
ok, so apple has no firmware adapter, etc. can we discuss what would be the next obvious thing to do
<bgilbert>
to be clear, from context I'm assuming you mean a platform-independent default, similar to how /boot/ignition/config.ign is a platform-independent default
<bgilbert>
there are _platform-dependent_ default network sources, i.e. on AWS the config is on 169.254.169.254 and we know that's safe because AWS prevents anyone else from using it
<bgilbert>
however, we can't do that for e.g. bare metal because we know nothing about the network we're running on
<baude>
ok, fair enough, hence why i ask about whats next ... the apple hv boots the baremetal raw image just fine ... ideas?
<bgilbert>
I don't know how Mac virt is set up, but I assume the network configuration is configurable? i.e. you can do bridged, or NAT, or whatever
<bgilbert>
if there's an IP address which is always, always, something under the host's control, we could consider using that
<baude>
it is configurable, yes, but there is not that
<baude>
so sounds like network is out
<bgilbert>
yeah, if the network config is arbitrarily flexible, we can't make assumptions that some IP address A.B.C.D is always safe
<baude>
understood, whats the next idea
<baude>
you also dont want block devices yes?
<bgilbert>
it sounds like we may not have a choice
<bgilbert>
there's no host-guest communication mechanism at all?
<baude>
no\
<baude>
and we must have a choice
plarsen has quit [Remote host closed the connection]
<bgilbert>
I meant we may have to use a block device
<baude>
oh
<baude>
yes
<baude>
i can take a second look
<baude>
bgilbert: virtio-fs ?
<bgilbert>
baude: hmm. is that available?
<baude>
virtio-fs uses mountTags, so we could have something specific like mountTag = "Ignition" ... and read it from there
<baude>
yes sir, got it working last week
<bgilbert>
do you have a link to the virtualization system you're looking at? I googled "apple hv" and only found the generic kernel API for building virtualization systems
<baude>
i guess the question is if the stuff we need is in the initrd
<baude>
that is what im walking through to look for more ideas
<bgilbert>
baude: okay, so the user-facing interface isn't an existing GUI like VirtualBox, it's something you're implementing using this API?
<baude>
in spirit correct, but i am using a cmd line tool made by the crc team called vfkit, which in turn uses a project called vz which are just go bindings for the applehv
<bgilbert>
okay. that gives us a bit more flexibility, then. there are a bunch of virtio interfaces and we can require the host code to use one in a particular way
<bgilbert>
i.e. we don't have to use something that can fit in an existing config file
<baude>
not sure i follow, can you elaborate ?
<bgilbert>
I am not proposing this, but as an example: we could say "hypervisors that want to support Ignition must create a network device with a specific MAC address and IP address and an HTTP server listening on that address"
<bgilbert>
we don't have compat requirements with existing hypervisors, so we can require arbitrary code to run on the host
<dustymabe>
bgilbert: i'm honestly not sure on that one. I don't understand why we're not seeing it in things like CI for f-c-c ?
<bgilbert>
¯\_(ツ)_/¯
<bgilbert>
it's consistently failing in Afterburn
<bgilbert>
dustymabe: f-c-c has cosaPod(cpus: 4, memory: "9Gi")
<bgilbert>
coreos-installer does not, but CI is passing there
<dustymabe>
yeah.. and coreos-installer even runs testiso
<dustymabe>
I wonder if this is more of a problem of the tests not specifying a value at all for memory
<dustymabe>
though really looking at the logs the test is even failing when it's run by itself
<dustymabe>
honestly maybe some memory leak?
<dustymabe>
but yeah.. really feels like we would see this in f-c-c
<dustymabe>
the test VM itself should only be getting 1024m regardless
<dustymabe>
i'm guessing you can't reproduce locally?
<bgilbert>
Afterburn is already denylisting ext.config.kdump.crash due to an unexplained failure that only affected Afterburn
<bgilbert>
oh wait
<dustymabe>
cydox[m]: thanks!
<bgilbert>
dustymabe: it's because Afterburn CI installs a 152 MB binary into the initrd
<dustymabe>
bgilbert: on purpose?
<bgilbert>
that's what I'm trying to figure out. stripping debug symbols takes it down to 8 MB. it's nice to have debug symbols so we get backtraces in CI, but if it's going to keep breaking our tests, that's unhelpful
<dustymabe>
ah - makes sense
<bgilbert>
I'm inclined to strip the symbols and stop playing whack-a-mole. wdyt?
<dustymabe>
yeah - looking at the logs now
<dustymabe>
so basically in this tests Ignition is creating luks containers etc.. the extra 150M in the initrd (all in RAM during this phase of boot) means we get pushed over the edge
<bgilbert>
yup
<dustymabe>
if the debug symbols are important we *could* just bump minMemory for this test in f-c-c
<dustymabe>
with a nice comment
<dustymabe>
otherwise, stripping the debug symbols SGTM
<dustymabe>
and yeah the latter probably would be better because other tests could bump up into this in the future (i.e. the whack-a-mole you mentioned)
<dustymabe>
maybe we could add some instructions on how to undo the symbol stripping in a PR to get more output if a test failure isn't easily explained
<bgilbert>
I'll put up a PR with a comment in the .cci.jenkinsfile
<dustymabe>
thanks!
<dustymabe>
mind updating the tracker issue when you're done too?
<dustymabe>
i'm glad we figured that out.. it was definitely confusing
<bgilbert>
+1
<bgilbert>
walters: I haven't added the cap-std-ext CI job to repo-templates because it's somewhat different than the other Rust jobs. should I do that, or leave as is?
Betal has joined #fedora-coreos
<walters>
bgilbert: I'm good with re-paving that
<bgilbert>
+1
<baude>
bgilbert: so, are we in agreement that I should pursue a socket based communication approach where the host feeds the guest? and then open up a new platform thingy ?
<bgilbert>
baude: yeah, sgtm
<bgilbert>
walters: I'll fix the branch protection and the clippy lints
<baude>
bgilbert: also, whats the plan re: hyperv and ignition ?
<bgilbert>
baude: I need to find some cycles to get back to those reviews
saschagrunert has quit [Remote host closed the connection]
jpn has joined #fedora-coreos
jpn has quit [Ping timeout: 250 seconds]
jpn has joined #fedora-coreos
sentenza has joined #fedora-coreos
<nirik>
I'm looking at updating the fedora prod openshift cluster later today. Let me know if theres a better/worse time for it. Its just a minor version update, nothing too exciting and nothing should be down very log/much.
jpn has quit [Ping timeout: 250 seconds]
<dustymabe>
nirik: go for it
<dustymabe>
now is good :)
<nirik>
k
gursewak has quit [Ping timeout: 240 seconds]
jpn has joined #fedora-coreos
jpn has quit [Ping timeout: 250 seconds]
<dustymabe>
nirik: mind a favor for me since you are a proven packager?