arnulfo_7 has quit [Read error: Connection reset by peer]
gursewak has joined #fedora-coreos
jpn has joined #fedora-coreos
jpn has quit [Ping timeout: 268 seconds]
gursewak has quit [Ping timeout: 244 seconds]
jpn has joined #fedora-coreos
jpn has quit [Ping timeout: 272 seconds]
bgilbert has quit [Read error: Connection reset by peer]
bgilbert_ has joined #fedora-coreos
jpn has joined #fedora-coreos
jpn has quit [Ping timeout: 268 seconds]
paragan has joined #fedora-coreos
bgilbert_ has quit [Ping timeout: 240 seconds]
qinqon has joined #fedora-coreos
jcajka has joined #fedora-coreos
jpn has joined #fedora-coreos
gursewak has joined #fedora-coreos
jpn has quit [Ping timeout: 246 seconds]
tormath1 has joined #fedora-coreos
paragan has quit [Ping timeout: 268 seconds]
paragan has joined #fedora-coreos
jpn has joined #fedora-coreos
gursewak has quit [Ping timeout: 264 seconds]
jpn has quit [Ping timeout: 272 seconds]
heldwin has joined #fedora-coreos
jpn has joined #fedora-coreos
qinqon has quit [Quit: WeeChat 3.5]
qinqon has joined #fedora-coreos
<qinqon>
Hi, we are checking ignition providers and found that if configuration is provided using a config drive then the ignition.url option is ignored.
<qinqon>
It would be possible at cloud env to pass ignition throw config drive and config url so the basics to access the URL is configured at config drive ?
Betal has quit [Quit: WeeChat 3.5]
<tormath1>
qinqon: hi, what would be the "basics to access the URL" ? If I understand correctly you'd like to provide two Ignition configurations ?
<qinqon>
tormath1: at non DHCP scenarios you need to set IP configuration to access ignition url for example
<qinqon>
tormath1: nowadays you can do that with dracut, but maybe mixing config drive + ignition url you don't need dracut at all ?
<qinqon>
tormath1: that's a case where user cannot put all the config at config drive for whatever reason
jpn has quit [Ping timeout: 272 seconds]
<tormath1>
qinqon: thanks for elaborating, I get your point. Network configuration from Ignition configuration is applied on the _real_ root, so even with config drive + ignition URL mixing I'm not sure we'll be able to pull the configuration. That's why we need to go with network kernel arguments (like `ip=`)
<qinqon>
tormath1: What means _real_ root ? (sorry if this is a simple quesion)
<tormath1>
qinqon: by real root, I mean the root filesystem after pivoting from the initramfs to the machine's root filesystem.
paragan has quit [Ping timeout: 256 seconds]
<qinqon>
tormath1: config drive ignition is applied before pivot ?
jpn has joined #fedora-coreos
paragan has joined #fedora-coreos
jpn has quit [Ping timeout: 240 seconds]
paragan has quit [Quit: Leaving]
jpn has joined #fedora-coreos
paragan has joined #fedora-coreos
jpn has quit [Ping timeout: 246 seconds]
<tormath1>
qinqon: I don't know for config drive, I never tried yet. :)
<dustymabe>
all Ignition is applied in the initramfs (before pivoting)
<dustymabe>
qinqon: it's my understanding that if you provide ignition.config.url=http://.... that will get used over the platform's default mechanism.. my memory could be mistaking me, though
jpn has joined #fedora-coreos
<qinqon>
dustymabe: the networking applied at initramfs is lost after pivoting right ?
crobinso has joined #fedora-coreos
mheon has joined #fedora-coreos
<dustymabe>
qinqon: only if you provided more networking via Ignition
<dustymabe>
"Any configuration provided via Ignition will be considered at a higher priority than any other method of configuring the Network for a Fedora CoreOS instance. If you specify Networking configuration via Ignition, try not to use other mechanisms to configure the network."
frigo has joined #fedora-coreos
<dustymabe>
if you don't provide any networking via Ignition, then what is in the initramfs will be propagated forward (assuming it's non-default).
<dustymabe>
qinqon: do you know who I could talk to about possibly using /etc/NetworkManager/nmstate/ instead of /etc/nmstate/ ? seems cleaner to me if we could put it under the NetworkManager dir
<qinqon>
dustymabe: yep commenting out the PR looks fine, although you are writting at a directory created from different RPM don't know if this can be a problem
nalind has joined #fedora-coreos
<dustymabe>
does nmstate depend on the RPM that creates the directory?
<qinqon>
dustymabe: think so
<dustymabe>
if that's the case then it should be OK?
<walters>
but hopefully the real fix will be folding it into `cargo vendor`
jpn has joined #fedora-coreos
jpn has quit [Ping timeout: 246 seconds]
<jlebon>
saqali: sorry, busy day. :) i can do anytime >= 15:30
<saqali>
jlebon: cool will ping you and dustymabe then :)
heldwin has quit [Remote host closed the connection]
heldwin has joined #fedora-coreos
crobinso has quit [Remote host closed the connection]
mboddu_ has quit [Changing host]
mboddu_ has joined #fedora-coreos
mboddu_ is now known as mboddu
hiredman has quit [Ping timeout: 246 seconds]
Betal has quit [Ping timeout: 246 seconds]
Betal has joined #fedora-coreos
fifofonix has joined #fedora-coreos
<fifofonix>
did both next and testing jump to 5.18.5 simultaneously with this release cycle, and if so was there a reason?
<dustymabe>
fifofonix: next and testing are in lockstep right now (they have the same exact content)
<fifofonix>
dustymabe: but, that content wasn't first released to next, and then subsequently released to test?
<dustymabe>
fifofonix: `next` and `testing` don't have a direct relationship like `testing` and `stable` do
<fifofonix>
dustymabe: i think in this situation some fallout bled for me into my test environment, that normally i'd expect to catch in my 'next' based dev environment.
<dustymabe>
basically we'll put experimental features OR Fedora major rebases in `next` first
<dustymabe>
but at times like this right now, Fedora 37 is too new/doesn't exist yet, and we don't have any new features we are experimenting with
<dustymabe>
so it's just a carbon copy of `testing`
<fifofonix>
hmm. but shouldn't what is in testing (which is new) have gone through next first?
<dustymabe>
:) - it doesn't quite work like that (as mentioned above)
<dustymabe>
`testing` -> 2 weeks -> `stable`
<dustymabe>
that's a guarantee ^^
<dustymabe>
well - we try to make it true
<dustymabe>
but `next` -> 2 weeks -> `testing` is not something we do
<dustymabe>
does that make sense?
<fifofonix>
dustymabe: stewing on it rn, and wondering whether i need to re-evalute my deployments.
ravanelli has quit [Remote host closed the connection]
<dustymabe>
the content set will be the same between `testing` and `next`, but nodes will be configured differently
<dustymabe>
that's an example of using `next` for experimentation of features before they go to `testing`
<dustymabe>
IOW, we make big changes in next first typically, so in that sense `next` will lead `testing`.. but for normal package updates, we don't make any special efforts there
<dustymabe>
still, you have a testing env which caught the issue? which means you still caught it before stable?
paragan has joined #fedora-coreos
<fifofonix>
dustymabe: thanks for the details, amazing that i hadn't fully appreciated this given i've been using fcos since pretty much its inception. maybe i carried forward a mental mistake from coreos days. not a big deal.
<fifofonix>
dustymabe: correct, you guys ship high quality and so the reason my misapprehension has gone on so long is because there have been very few issues occurring in test (and the bigger changes have come through next - which you know we run).
<fifofonix>
dustymabe: in case you're interested the step to 5.18 requires newer NVIDIA driver versions or compilation errors occur (reviewing chat from past few days I see stereobutter may be doing something interesting in the NVIDIA driver space).
<dustymabe>
fifofonix: ahh, so there's some sort of NVIDIA drivers in a container you are using that aren't compatible with 5.18 ?
gursewak has quit [Remote host closed the connection]
<dustymabe>
saqali: jlebon: available now?
<saqali>
yes let's do it
<jlebon>
yup
<fifofonix>
dustymabe: correct, i've forked the nvidia driver container project and automatically rebuild set driver versions daily pushing the images. this runs under systemd/podman but the running driver is accessible from other containers that then use the GPU.
paragan has quit [Quit: Leaving]
jbrooks has quit [Ping timeout: 240 seconds]
jbrooks has joined #fedora-coreos
ravanelli has joined #fedora-coreos
ravanelli has quit [Remote host closed the connection]
jpn has joined #fedora-coreos
jpn has quit [Ping timeout: 268 seconds]
jbrooks has quit [Ping timeout: 272 seconds]
ravanelli has joined #fedora-coreos
nalind has quit [Quit: bye]
jbrooks has joined #fedora-coreos
ravanelli has quit [Remote host closed the connection]