dustymabe changed the topic of #fedora-coreos to: Fedora CoreOS :: Find out more at https://getfedora.org/coreos/ :: Logs at https://libera.irclog.whitequark.org/fedora-coreos
gursewak_ has quit [Ping timeout: 260 seconds]
ravanelli has joined #fedora-coreos
vgoyal has joined #fedora-coreos
vgoyal has quit [Client Quit]
jtgreene has quit [Quit: fBNC - https://bnc4free.com]
ravanelli has quit [Remote host closed the connection]
jtgreene has joined #fedora-coreos
jtgreene has quit [Changing host]
jtgreene has joined #fedora-coreos
jtgreene has quit [Ping timeout: 246 seconds]
jtgreene has joined #fedora-coreos
jtgreene has joined #fedora-coreos
jtgreene has quit [Changing host]
misuto has quit [Remote host closed the connection]
misuto has joined #fedora-coreos
jpn has joined #fedora-coreos
jpn has quit [Ping timeout: 256 seconds]
daMaestro has joined #fedora-coreos
gursewak_ has joined #fedora-coreos
pej0703 has joined #fedora-coreos
samuelb has joined #fedora-coreos
hank_ has joined #fedora-coreos
hjst_ has joined #fedora-coreos
gursewak_ has quit [*.net *.split]
pej070 has quit [*.net *.split]
hjst has quit [*.net *.split]
samuelbernardo has quit [*.net *.split]
jzelinskie has quit [*.net *.split]
hank has quit [*.net *.split]
jcajka has joined #fedora-coreos
gursewak_ has joined #fedora-coreos
Betal has quit [Quit: WeeChat 3.7.1]
jzelinskie has joined #fedora-coreos
c4rt0 has joined #fedora-coreos
saschagrunert has joined #fedora-coreos
daMaestro has quit [Quit: Leaving]
ravanelli has joined #fedora-coreos
ravanelli has quit [Remote host closed the connection]
frytaped is now known as go4godvin
ravanelli has joined #fedora-coreos
frytaped has joined #fedora-coreos
frytaped has quit [Quit: WeeChat 3.6]
frytaped has joined #fedora-coreos
frytaped has quit [Quit: WeeChat 3.6]
tormath1 has joined #fedora-coreos
frytaped has joined #fedora-coreos
<tormath1> hey there, I was playing a bit with Flatcar and Linode - it seems that Ignition does not support Linode provider.
<tormath1> I did not find anything on the coreos/ignition repo related to Linode. Did you already get some requests about it?
vgoyal has joined #fedora-coreos
<tormath1> I quickly checked, Linode does not have instance metadata service like many other cloud providers - but it has a "StackScript" concept that could be use in the same way
jcajka has quit [Ping timeout: 252 seconds]
<miabbott[m]> tormath1: if you are looking for Flatcar folks, they probably hang out at #flatcar:matrix.org
<miabbott[m]> their fork of Ignition lives at https://github.com/flatcar/ignition
<tormath1> miabbott[m]: thanks for the answer, I am a member of the Flatcar maintainer team - my question was more about Ignition itself, that's why I asked on this channel. :)
<miabbott[m]> ohhhhh
<miabbott[m]> it doesn't look like there is an official provider in coreos/ignition for Linode...the most interesting bits that I found was https://discussion.fedoraproject.org/t/coreos-on-linode/41007
jcajka has joined #fedora-coreos
<miabbott[m]> I'm actually surprised that we don't have any issues in coreos/ignition or coreos/fedora-coreos-tracker asking for Linode support...
<tormath1> (and for the record, Flatcar is now using the actual coreos/ignition with a few Flatcar patches applied at the build time, we try to be closer to the upstream to merge the efforts :heart: )
<miabbott[m]> cool!
<tormath1> thanks for the link - I am curious to see how stackscripts would work. According to Benjamin answer, it seems that it modifies the disk directly.
<tormath1> my idea would be to write Ignition configuration as a StackScript then to use the Linode SDK to fetch the configuration from this stackscript
frytaped has quit [Quit: WeeChat 3.6]
<tormath1> but we would need some token or credentials to fetch the configuration from the instance...
<tormath1> because for now, I install Flatcar using the installer (same as coreos-installer) - and I pass the Ignition configuration at this time but it's not really flexible
nalind has joined #fedora-coreos
tormath1 has quit [Ping timeout: 255 seconds]
tormath1 has joined #fedora-coreos
mheon has joined #fedora-coreos
<miabbott[m]> found this complaint about FCOS on Twitter...not sure it is worth responding to - https://twitter.com/0xBADC0DEC/status/1598263815610564608
jcajka has quit [Ping timeout: 256 seconds]
<travier[m]> They should probably give NetworkManager a try :)
<dustymabe> miabbott[m]: nope
<dustymabe> their tone is not something I'm willing to engage with
<miabbott[m]> agreed
<travier[m]> <tormath1> "my idea would be to write..." <- I've no idea how this works on Linode but that sounds like a potential path forward. If we can write the Ignition config in a Linode specific format that is per-instance and then use it to write the config on the boot partition, then that should work
<travier[m]> (to be clear, I won't engage either, and not on twitter anymore
<travier[m]> )
<travier[m]> tormath1: Feel free to make an issue for Ignition with your findings!
<tormath1> travier[m]: thanks, I will open a tracking issue. Even if it leads to nothing, we will have reference for history purposes :)
<travier[m]> tormath1: 👍️
jcajka has joined #fedora-coreos
<tormath1> travier[m]: issue is opened (#1508), feel free to edit / comment if I forgot something.
saschagrunert has quit [Quit: Leaving]
frytaped has joined #fedora-coreos
<travier[m]> tormath1: thanks
frytaped has quit [Quit: WeeChat 3.6]
jcajka has quit [Quit: Leaving]
<dustymabe> jlebon: got a weird scenario going on here.
<dustymabe> there are two rawhide mArch builds that are waiting on a lock to get released from builds that started days ago
<dustymabe> ahh interesting. the builds that they are waiting on are the ones that had the `flownodes` errors
Betal has joined #fedora-coreos
travisghansen has quit [Read error: Connection reset by peer]
<jlebon> dustymabe: ouch
<dustymabe> might have to reboot jenkins? or do you think the lock info is stored in the PVC?
<jlebon> can you link me to the waiting job?
<jlebon> i'd be surprised
<dustymabe> it's the two jubs here that have been running for 3.5 hours: https://jenkins-fedora-coreos-pipeline.apps.ocp.fedoraproject.org/job/build-arch/
<dustymabe> s/jubs/jobs
<dustymabe> and you'll notice there were two other jobs recently that timed out waiting on those locks too
cyberpear has joined #fedora-coreos
<jlebon> hmm, that jenkins was respawned two days ago (when i rolled out the cert and bc renames change), which is after the flownodes job
travisghansen has joined #fedora-coreos
<dustymabe> fun
<jlebon> let's try another restart to confirm, but it's possible indeed that it's on the PVC
<dustymabe> ok I'll cycle jenkins
<jlebon> dustymabe: some indications in https://issues.jenkins.io/browse/JENKINS-55287 that it may be memory related
<jlebon> we're currently at 2Gi
<jlebon> we can try bumping to 4Gi and see if it we still hit this
<dustymabe> +1 to bump - do we need to double it, though? 3Gi enough?
<dustymabe> ok - after reboot tried to start the job again and: `[build-rawhide-s390x] is locked by build-arch #774, waiting...`
<jlebon> i mean, both those numbers are peanuts for those machines. :) good with 4Gi though. will prep that.
<jlebon> ok, let me dig into the lock thing
hank_ is now known as hank
<jlebon> s/4/3/
<dustymabe> 👍
<jlebon> i already unlocked the broken ones
c4rt0 has quit [Remote host closed the connection]
* jlebon goes for food
<dustymabe> cool thanks
tormath1 has quit [Quit: leaving]
travisghansen has quit [Ping timeout: 256 seconds]
<jlebon> dustymabe: we need to backport https://github.com/coreos/coreos-assembler/pull/3254. should I do that now or wait until you've migrated the branches?
<jlebon> actually, not all branches have https://github.com/coreos/coreos-assembler/commit/e4d5d1ee0725fb99bfd0041c707abaeb307e3dbe so maybe not. need to check their labels
cyberpear has quit [Quit: Connection closed for inactivity]
<dustymabe> jlebon: I think there are probably a few other things that need backporting too.. should we come up with a list and just add them to the "merge 4.x-new into 4.x" PRs ?
<jlebon> dustymabe: yeah, makes sense to me
<jlebon> should we do a hackmd?
<dustymabe> jlebon: SGTM - i'm on a call, but will collaborate on a hackmd if you want to make it
<dustymabe> jlebon: cool - is that all? If so I'll get on making the PRs (with those backports included)
<jlebon> dustymabe: if you have the inspect and creds command hot, can you double-check which branches need the quote fix backport?
<dustymabe> jlebon: I don't have creds - I was just running the inspect on the ociarchive file - but I can grab them for the various branches and see which ones need it
<jlebon> dustymabe: ahh gotcha. cool, thanks!
<jlebon> but yeah, otherwise I *think* that's all
<dustymabe> jlebon: I don't see this in the older releases (older than 4.13): https://github.com/openshift/os/blob/53bb4ec662ad41f95adccd676366acf5fd8014be/image-rhel-8.6.yaml#L12
<dustymabe> ahh, nevermind, I thought they were related, but legacy os-container has been doing this since before that image.yaml entry existed
<jlebon> dustymabe: yeah, that's to do it for the new format. but it doesn't matter for older releases
<dustymabe> jlebon: I just checked the legacy oscontainer for 4.12 and 4.11
<dustymabe> 4.12: "io.openshift.build.version-display-names": "machine-os=\"Red Hat Enterprise Linux CoreOS\"",
<dustymabe> 4.11: "io.openshift.build.version-display-names": "machine-os=Red Hat Enterprise Linux CoreOS",
<dustymabe> ^^ from most recent builds in the new pipeline
<jlebon> dustymabe: ahh nice
<jlebon> so that means we need to backport it to 4.12 only
<dustymabe> ok let me start on these backports
<jlebon> +1
<dustymabe> this let's us drop the dotlockfile hacks we had put in place: https://github.com/coreos/fedora-coreos-config/pull/2115
<dustymabe> jlebon: do we want https://github.com/coreos/coreos-assembler/pull/3246 backported to 4.12 too?
ravanelli has quit [Remote host closed the connection]
<dustymabe> probably also going to need a variant of https://github.com/coreos/coreos-assembler/pull/3250 - but I guess we can wait to see if failures happen before we backport that one
<dustymabe> ok I added #3246 to the backport PR
<jlebon> dustymabe: re. #3246, it's not strictly necessary, but it'd be nice if it's easy to save electricity. it should be backported to all the branches where the import_ostree_commit signature changed to workdir
<dustymabe> jlebon: we only build the extensions container for 4.12+ IIUC
<jlebon> dustymabe: that command is for the extensions RPMs that go into the legacy oscontainer
<dustymabe> re: 3250 +1
<jlebon> it's super confusing, but there's buildextend-extensions and buildextend-extensions-container
<dustymabe> jlebon: ahh - had missed that
<dustymabe> yep - makes sense
<jlebon> i'm not sure at what point we changed the import signature. do you want me to check?
<dustymabe> sure :)
<jlebon> k :)
<jlebon> looks like 4.12 and 4.11 only
<dustymabe> +1
<dustymabe> jlebon: do you think it's safe to backport https://github.com/coreos/coreos-assembler/pull/2785 too (so your plume commits will apply cleanly)?
<jlebon> dustymabe: i think it should be, but would it make to backport just that one line drop to release.go to be safe and keep it simple?
<jlebon> make sense*
<jlebon> we don't use and AFAIK have never used anything in `plume release` related to azure
<dustymabe> which one line drop to release.go?
<dustymabe> +1
<dustymabe> i'll try
<jlebon> that should be the only thing that causes conflicts
<jlebon> nice, thanks!
<dustymabe> i'm seeing more conflicts than that
<dustymabe> i'll try to resolve them tomorrow
<dustymabe> to be clear - the 4.11 backport when smooth
<dustymabe> i hit trouble when I got to 4.10
<jlebon> ahhh damn. ok, let's sync tmw!
mheon has quit [Ping timeout: 256 seconds]
vgoyal has quit [Quit: Leaving]
travisghansen has joined #fedora-coreos
nalind has quit [Quit: bye for now]