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