16:30:54 <kaeso[m]> #startmeeting fedora_coreos_meeting
16:30:54 <zodbot> Meeting started Wed Dec  4 16:30:54 2019 UTC.
16:30:54 <zodbot> This meeting is logged and archived in a public location.
16:30:54 <zodbot> The chair is kaeso[m]. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:30:54 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:30:54 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:31:14 <kaeso[m]> #topic roll call
16:31:41 <ajeddeloh> .hello2
16:31:42 <zodbot> ajeddeloh: ajeddeloh 'Andrew Jeddeloh' <andrew.jeddeloh@redhat.com>
16:31:52 <kaeso[m]> .hello lucab
16:31:53 <zodbot> kaeso[m]: lucab 'Luca Bruno' <lucab@redhat.com>
16:32:53 <dustymabe> .hello2
16:32:55 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:33:46 <jlebon> .hello2
16:33:47 <zodbot> jlebon: jlebon 'None' <jonathan@jlebon.com>
16:34:07 <walters> .hello2
16:34:07 <zodbot> walters: walters 'Colin Walters' <walters@redhat.com>
16:34:21 <kaeso[m]> #chair ajeddeloh dustymabe jlebon walters
16:34:21 <zodbot> Current chairs: ajeddeloh dustymabe jlebon kaeso[m] walters
16:36:08 <kaeso[m]> while we wait for other people to maybe join...
16:36:25 <kaeso[m]> we don't have any specific ticket under `meeting` today
16:36:37 <kaeso[m]> but we have a things going on right now
16:37:07 <kaeso[m]> including the F31 rebase and the new iteration of coreos-installer
16:37:37 <kaeso[m]> I can happily sum them up here as starting topics
16:37:45 <dustymabe> kaeso[m] +1
16:37:57 <kaeso[m]> (I think my bridge has a bit latency, sorry for that)
16:38:40 <kaeso[m]> #topic F31 rebase on the testing stream
16:39:30 <kaeso[m]> this is one is mostly completed at this point now, I'd say
16:39:48 <kaeso[m]> release happened last week
16:39:51 <kaeso[m]> https://github.com/coreos/fedora-coreos-streams/issues/29
16:40:34 <kaeso[m]> there were a few bumps and some delays, also because of US holidays
16:41:08 <kaeso[m]> Rollout started yesterday: https://github.com/coreos/fedora-coreos-streams/pull/32
16:41:45 <kaeso[m]> it is currently ongoing, at around 50% right now
16:42:31 <kaeso[m]> if anybody spots failures after or during the auto-updates, please report it to the -tracker
16:43:16 <dustymabe> +1, hopefully all goes smooth
16:43:25 <kaeso[m]> as a side-note, we also had to tag an extra F30 release
16:44:06 <kaeso[m]> the reason is explained here: https://github.com/coreos/fedora-coreos-streams/issues/30
16:44:38 <kaeso[m]> it was not planned, but still a good occasion to polish and check the barrier logic for auto-updates
16:45:19 <dustymabe> thanks to luca jlebon and bgilbert for helping get the f31 release out
16:45:51 <kaeso[m]> that's all I have on this one, any other point or question?
16:46:48 <kaeso[m]> ok, I'll go to the next one on my list
16:46:52 <jlebon> yeah, i really like that we were able to leverage the barrier work :)
16:47:17 <kaeso[m]> #topic next iteration on coreos-installer
16:47:47 <kaeso[m]> bgilbert is not around today, but he has been doing most of the work on this one
16:48:46 <kaeso[m]> the idea is that the current coreos-installer is a bit limited in its environment, due to initramfs constraints
16:49:34 <kaeso[m]> also, it was growing a bit too much logic and LoC for a shell-script
16:49:59 <kaeso[m]> the next iteration of that already landed on master
16:50:21 <kaeso[m]> and the documentation is being updated too
16:50:26 <kaeso[m]> #link https://github.com/coreos/coreos-installer
16:50:46 <dustymabe> bgilbert++
16:50:46 <zodbot> dustymabe: Karma for bgilbert changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:51:05 <kaeso[m]> it can now be consumed as a normal systemd service in a full environment
16:51:08 <dustymabe> kaeso[m]: do you know what the status is there. is anyone going to be able to pick up where he left off while he is out
16:51:54 <kaeso[m]> dustymabe: I think he synced everything to the internal ticket on your team board
16:52:10 <dustymabe> +1
16:52:41 <kaeso[m]> dustymabe: to the best of my knowledge, there is a bit of "packaging for Fedora" pending
16:53:43 <kaeso[m]> dustymabe: and then there is the integration part for moving it out of the initramfs
16:54:49 <dustymabe> kaeso[m]: understood
16:54:51 <dustymabe> thanks
16:55:08 <kaeso[m]> now we are also building a container for consuming it outside of *COS
16:55:38 <kaeso[m]> #link https://quay.io/repository/coreos/coreos-installer?tab=tags
16:56:35 <kaeso[m]> we already got some reports from a user on centos-7, and the fixes are on master
16:57:36 <kaeso[m]> I guess that's all I have on this
16:58:29 <kaeso[m]> we got https://github.com/coreos/coreos-installer/issues/106 reported just today
16:58:56 <kaeso[m]> but I think we can simply tweak the metadata on our side for the time being
16:59:44 <kaeso[m]> end of my monologue, I guess :)
16:59:55 <dustymabe> ha - i like all of the context
17:00:17 <kaeso[m]> anybody with a well-scoped topic to cover?
17:00:48 <kaeso[m]> or we can just proceed to the open-floor
17:00:49 <dustymabe> i've got something for open floor
17:00:56 * ajeddeloh has nothing
17:01:13 <kaeso[m]> #topic open floor
17:02:12 <dustymabe> regarding python3 in https://github.com/coreos/fedora-coreos-tracker/issues/280
17:02:27 <dustymabe> ajeddeloh: is that on your queue?
17:02:35 <dustymabe> I notice that you are the assignee
17:03:25 <dustymabe> #info opened an infra ticket to discuss signing GitHub project release artifacts: https://pagure.io/releng/issue/9057
17:03:34 <dustymabe> ^^ separate topic, but relevant
17:03:48 <ajeddeloh> its fallen on the backburner, I can make it a priority though
17:05:12 <dustymabe> it'd be nice since it'll probably need some lead time to filter through some processes
17:05:25 <dustymabe> thanks ajeddeloh
17:05:44 <dustymabe> regarding "signing GitHub project release artifacts" can I ask a few questions on that?
17:05:53 <ajeddeloh> +1
17:07:07 <dustymabe> basically the goal of that is so that we can put the artifacts here and sign them with an appropriate key https://github.com/coreos/ignition/releases/tag/v2.0.1
17:07:16 <dustymabe> so i.e. detached signatures
17:07:55 <ajeddeloh> right
17:08:48 <dustymabe> ok, we don't care about signing the binary so that windows/mac don't show a warning the user about the source of the program being unverifiable ?
17:09:58 <ajeddeloh> hadnt thought of that
17:10:20 <dustymabe> in the meeting I had with releng today they thought I was talking about signing the binaries
17:10:26 <dustymabe> apparently that's an involved process
17:10:30 <ajeddeloh> I dont think its as important as having signatures at all
17:10:35 <dustymabe> +1
17:10:39 <dustymabe> we'll go with that for now then
17:10:50 <dustymabe> the other question is: `How can we build for other platforms?`
17:10:51 <ajeddeloh> like that would be neat, but it sounds like more work than its worth
17:11:03 <ajeddeloh> golang can cross compile
17:11:05 <dustymabe> is setting GOOS variable enough ?
17:11:07 <dustymabe> https://github.com/coreos/ignition/blob/v2.0.1/build_releases#L36-L50
17:11:10 <ajeddeloh> yeah
17:11:44 <kaeso[m]> (I know I already voiced this in the past and we didn't agree, but I'd still hope we could point users to "pull this container image by hash" instead of "static binary + gpg")
17:12:19 <dustymabe> ajeddeloh: I made a comment to the ticket with these questions: https://pagure.io/releng/issue/9057#comment-614839
17:12:28 <dustymabe> i'll go in and answer them in a followup comment
17:12:40 <ajeddeloh> +1
17:12:55 <dustymabe> thanks ajeddeloh
17:12:57 <ajeddeloh> kaeso[m]: why not both?
17:13:08 <dustymabe> kaeso[m]: yeah. I think the biggest problem is windows/mac..
17:13:31 <dustymabe> though now that containers are prevalent (linux containers specifically) it seems like a linux binary in a container might suffice
17:13:50 <dustymabe> because the other platforms have ways to run linux containers now
17:13:51 <kaeso[m]> dustymabe: fair
17:14:11 <dustymabe> ok that's mostly it from me
17:14:40 <kaeso[m]> ajeddeloh: distributors (brew / nuget) can do that better than us. If anybody cares to have it there, they'll package it.
17:15:40 <ajeddeloh> hmm fair
17:16:03 <ajeddeloh> we also dont know if anyone uses the mac/windows fcct binaries
17:16:12 <ajeddeloh> or ign-validate
17:16:32 <kaeso[m]> anyway, I don't want to drag it here on and on, just wanted to record a "I don't completely agree"
17:17:50 <ajeddeloh> kaeso[m]: I think signed binaries make sense at least on linux
17:17:51 <dustymabe> kaeso[m]: i'm not opposed to the container image
17:18:02 <ajeddeloh> but in addition to container images
17:18:04 <dustymabe> just saying it's probably a "in addition to"
17:18:22 <ajeddeloh> jynx, you owe me a soda
17:18:26 <dustymabe> haha
17:18:39 <kaeso[m]> ajeddeloh: do we already autobuild an ign-validate container?
17:18:44 <dustymabe> ajeddeloh: are you saying one option is that we only ship a linux binary and a linux container image (i.e. don't worry about windows/mac) ?
17:18:55 <ajeddeloh> no, but that'll be easy to di
17:18:57 <ajeddeloh> do*
17:19:34 <dustymabe> right. if that's preferrable then we don't have to worry about crosscompiling
17:19:41 <kaeso[m]> ajeddeloh: ack, can you self-action that, low-prio?
17:19:44 <ajeddeloh> dustymabe: possibly, but I do worry that it creates a barrier to adoption if there is no brew/nuget package
17:20:06 <ajeddeloh> #action ajeddeloh to create an ignition-validate container
17:20:35 <ajeddeloh> apparently not
17:21:13 <kaeso[m]> weird
17:21:14 <kaeso[m]> #action ajeddeloh to create an ignition-validate container
17:22:31 <kaeso[m]> bah, ok, a ticket on GH/Jira will do
17:23:06 <kaeso[m]> dustymabe: other things?
17:24:33 <kaeso[m]> or anybody else?
17:25:02 <kaeso[m]> otherwise I'm going to close this in a minutes
17:25:44 <dustymabe> nope
17:25:46 <dustymabe> close out
17:25:48 <dustymabe> thanks kaeso[m]!
17:26:01 <ajeddeloh> kaeso[m]++
17:26:06 <kaeso[m]> ack
17:26:09 <kaeso[m]> #endmeeting