Mike[m] has quit [Quit: Client limit exceeded: 20000]
bytehackr has joined #fedora-coreos
Betal has quit [Quit: WeeChat 3.8]
jpn has joined #fedora-coreos
jpn has quit [Ping timeout: 255 seconds]
jpn has joined #fedora-coreos
saschagrunert has joined #fedora-coreos
jpn has quit [Ping timeout: 255 seconds]
jpn has joined #fedora-coreos
jpn has quit [Ping timeout: 276 seconds]
jcajka has joined #fedora-coreos
bgilbert has quit [Ping timeout: 255 seconds]
paragan has joined #fedora-coreos
jpn has joined #fedora-coreos
jpn has quit [Ping timeout: 276 seconds]
jpn has joined #fedora-coreos
fifofonix has joined #fedora-coreos
saschagrunert has quit [Remote host closed the connection]
vgoyal has joined #fedora-coreos
azukku has joined #fedora-coreos
jpn has quit [Ping timeout: 276 seconds]
jpn has joined #fedora-coreos
saschagrunert has joined #fedora-coreos
saschagrunert has quit [Remote host closed the connection]
jpn has quit [Ping timeout: 276 seconds]
jpn has joined #fedora-coreos
jpn has quit [Ping timeout: 268 seconds]
mheon has joined #fedora-coreos
daMaestro has quit [Quit: Leaving]
jpn has joined #fedora-coreos
jcajka has quit [Quit: Leaving]
plarsen has joined #fedora-coreos
jpn has quit [Ping timeout: 255 seconds]
jpn has joined #fedora-coreos
gursewak has joined #fedora-coreos
gursewak has quit [Ping timeout: 255 seconds]
<dustymabe>
jlebon: looks like beta is a GO for next Tuesday.
<jlebon>
dustymabe: sweet
<dustymabe>
There's a few things we need to do before next week
<dustymabe>
We need to come up with a communication about the coming changes (including ssh host key migration)
<dustymabe>
i'm running bump-lockfile for next-devel again right now to get the latest package set
<dustymabe>
i'll also run the process to make sure there are no downgraded packages from the previous `next` and then fast-track any that would be "downgrades"
<jlebon>
+1
<dustymabe>
and then I guess we can go ahead and do the build to prep for next tuesday and just release it on Tuesday morning
<dustymabe>
we can probably split it up.. someone does the coreos-status communication and someone does the release crank turning
fifofonix has quit [Read error: Connection reset by peer]
gursewak has quit [Read error: Connection reset by peer]
<dustymabe>
bgilbert: in platforms.yaml if a platform appears to support both serial and VGA console we default to VGA console being the last entry on the kernel command line, right?
<bgilbert>
dustymabe: could you expand on that?
<bgilbert>
we set the primary console for each platform based on its needs
<dustymabe>
I'm digging around on the kubevirt platform
<dustymabe>
when I booted an image the other day I notice the serial console option is available in the web UI but it didn't work (mainly because there is no platforms.yaml entry for it)
<dustymabe>
so I'm adding a platforms.yaml entry for kubevirt
<dustymabe>
now, kubevirt supports both serial and vga console it appears (both read/write)
<dustymabe>
so in that case what should we put in the platforms.yaml ?
<walters>
very tangential but there's an active discussion here of the intersection of bootable containers and kubevirt /payload 4.10 nightly informing
<bgilbert>
whichever console is emphasized in the UI
<bgilbert>
if one console is significantly better supported, that's relevant too
<walters>
if we made it so that kubevirt natively understood our container, interesting to think about what that might mean for exactly items like how the console is configured