<baude>
jlebon, you around re: my question from yesterday? i have a process followup question depending on what your final decision on the question was
plarsen has joined #fedora-coreos
nalind has joined #fedora-coreos
<jlebon>
baude: here, yup
<baude>
so you are fine with the PR?
<baude>
as is
<jlebon>
we're still talking about the pipeline PR, right?
<baude>
its kind of a nightmare having all these open PRs and keeping it straigt ... are they all held and merged at one time ?
<dustymabe>
travier[m]: the failure I linked you to is related to toolbox test failing - you think it's related to glib changes?
<baude>
dustymabe, ever heard of PTO?
<jlebon>
baude: they don't all have to merged at the same time
<baude>
particularily the TO part?
<jlebon>
but there's a certain order
<dustymabe>
baude: haha i'm in my ski gear about to hit the slopes
<jlebon>
we couldn't merge the pipeline PR before the cosa one for example
* baude
imagines dustymabe running into something on his skis because he is thinking about toolbox
<dustymabe>
def not - going to be thinking about not busting my butt
<baude>
jlebon, ok, fair enough ... how does the actual checklist work ?
<jlebon>
dustymabe: :)
<baude>
for example, i cannot actually check anything in the checklist off
<baude>
is that something you folks do as things merge or ?
<jlebon>
baude: yeah... i think you should've probably been the one to open the issue
<baude>
jlebon, and lastly, the one about fedora docs ...
<jlebon>
but we can probably give you access to check things off
<baude>
can that go dead last?
<baude>
jlebon, maybe it is better if you guys check them when you merge them? dununo, whatever you like
<jlebon>
baude: yes, it can
<jlebon>
well
<jlebon>
i'd say it can go dead before-last :) ideally we have docs before the artifact shows up on the website
<jlebon>
do you foresee issues with the docs part?
<baude>
jlebon, more a timing thing .. until my PRs for ignition are accepted, i cannot document how this is going to work ... and if i have to make code changes, i dont want to be stuck circling the toilet bowl
<baude>
so mostly trying to understand the overall process ... no reali concerns here other than running out of time
<jlebon>
baude: that's fine, we can build the artifact but not publicize it on the website and docs until it's ready
<jlebon>
if there are still doubts about how well it'll work, we can have it build for !prod streams only for now
<baude>
ok, like i said, just trying to understand things
<jlebon>
the main thing is Ignition support. once we have that, we could turn it on for the devel streams to make it easier to test.
<baude>
that would also be nice
<jlebon>
apart from the docs, all the other PRs in that checklist should be trivial and shouldn't take much time
<baude>
i think they are all done
<baude>
most need to be allowed to run their tests, etc
<baude>
so i think just ignition, the zip addition i did yesterday, and docs
<jlebon>
+1
<travier[m]>
<dustymabe> "travier: the failure I linked..." <- All podman related tests are failing as conmon is broken by the missing glib / rebuimd
<travier[m]>
s/rebuimd/rebuild/
<bgilbert>
baude: jlebon and I discussed the checklist issue. it seems easiest to close the issue and have you refile it yourself
<bgilbert>
jlebon: I think for CoreOS we always want to force Ignition to run in the live system
<bgilbert>
both ISO and PXE. even with persistent /var we need to know to mount it etc.
<bgilbert>
(ISO already does this, though in principle the karg can be edited out)
<bgilbert>
I'm seeing a few approaches: 1) add a new API similar to is-live-image
<bgilbert>
2) try to extend is-live-image by letting it print a token (though that unnecessarily conflates being a live image with forcing Ignition to run)
<bgilbert>
3) just using dracut's cmdline parsing so we get support for /etc/cmdline.d, and having CoreOS statically put ignition.firstboot in a cmdline.d file
<bgilbert>
3 is nice because we should arguably be using that mechanism anyway
<bgilbert>
wdyt?
<jlebon>
i think it makes sense, but i need to convince myself there's no use case we care about for not running Ignition
<jlebon>
does packet have ssh keys support?
<bgilbert>
IIRC yes
<jlebon>
indeed seems like it (grepping afterburn)
<bgilbert>
if we run Ignition and there's no config, it's a bit slower but harmless
<bgilbert>
I think this would only matter if the user provided a config but wants it not to run (again)
<bgilbert>
seems unlikely with the ISO (would require editing out the karg; might as well just edit out the embedded config0
<bgilbert>
)
<bgilbert>
for PXE, if they're using ignition.config.url= they can still remove that
<bgilbert>
and if they're using a `pxe customize` image or appended initrd, well, that's the user confusion issue we're trying to fix
<bgilbert>
i.e. the argument is that it's less confusing to always apply it than to require the user to ask to apply it
<bgilbert>
and if they're using ignition.platform.id=<non-metal> and cloud userdata, I guess they could drop the platform ID
<jlebon>
are there any concerns about the inconsistency between live and !live?
<bgilbert>
hmm. with live it's already the case that every boot is the first boot
<bgilbert>
and there are no auto-updates etc.
<bgilbert>
I think this is consistent with that?
<bgilbert>
I'm making these arguments, but yeah I'm not 100% convinced that nothing will break
<bgilbert>
it just seems like a strong balance of probabilities
<bgilbert>
also balancing between novice vs expert user etc
jpn has joined #fedora-coreos
<jlebon>
the only thing i can think of is people doing layered initrds where they have their own glue as an alternate way to provision the system, but not sure how realistic that is
<bgilbert>
oh, the other thing is that we should still support ignition.firstboot=0
<jlebon>
heh, was about to ask that. does that work today?
<bgilbert>
I don't know that we've tested it, but the code says so
<bgilbert>
and /proc/cmdline overrides /etc/cmdline*
<jlebon>
ok cool. i think with that it seems safer. so even in the worst case if someone is relying on Ignition not running, they could turn it back off
<jlebon>
we should probably remove ignition.firstboot from the ISO if we do this for consistency with PXE
<bgilbert>
agreed
<jlebon>
I was going to say PXE is special in that we don't control the kargs, but ISO is technically the same given users can change it how they want
<bgilbert>
yeah, though if users remove important ISO kargs, that's on them
<jlebon>
yeah, our API there is unclear
<bgilbert>
okay cool. there's an Ignition piece to this, and we want to release Ignition soon (Monday or Tuesday?) so I'll get some PRs up
<bgilbert>
thanks for the discussion!
<jlebon>
sounds good. thanks!
jpn has quit [Ping timeout: 268 seconds]
daMaestro has quit [Quit: Leaving]
cyberpear has quit [Quit: Connection closed for inactivity]
<baude>
bgilbert, there is no ignition requirement on the new platform support? seem odd?
<bgilbert>
in the checklist? we forgot to put one there
<bgilbert>
I'll start a comment with revisions
<baude>
hehehe
<bgilbert>
baude: I still owe you a followup on the Ignition PR