16:32:31 #startmeeting fedora_coreos_meeting 16:32:31 Meeting started Wed Mar 13 16:32:31 2019 UTC. 16:32:31 This meeting is logged and archived in a public location. 16:32:31 The chair is dustymabe. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:32:31 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:32:31 The meeting name has been set to 'fedora_coreos_meeting' 16:32:35 #topic roll call 16:32:37 .hello2 16:32:38 .hello2 16:32:38 jlebon: jlebon 'None' 16:32:41 dustymabe: dustymabe 'Dusty Mabe' 16:32:43 .hello2 16:32:44 ajeddeloh: ajeddeloh 'Andrew Jeddeloh' 16:32:47 .hello2 16:32:48 rfairley: rfairley 'None' 16:32:55 welcome everyone! hopefully nobody was thrown off with all of the 'time changes' 16:33:03 .hello lucab 16:33:05 .hello2 16:33:05 kaeso: lucab 'Luca Bruno' 16:33:08 yzhang: yzhang 'Yu Qi Zhang' 16:33:15 there's rumors CA may never switch back :D 16:33:33 ajeddeloh: yeah - is that official now? 16:33:34 .hello2 16:33:36 bgilbert: bgilbert 'Benjamin Gilbert' 16:33:45 no, but there's mounting pressure to do it 16:33:49 For a moment a thought you meant Canada 16:33:52 and not California 16:33:56 and I was happy 16:33:57 .fas jasonbrooks 16:33:57 jbrooks: jasonbrooks 'Jason Brooks' 16:34:11 .hello2 16:34:12 slowrie: slowrie 'Stephen Lowrie' 16:34:16 #info please add topics for the meeting to the etherpad https://public.etherpad-mozilla.org/p/20190313-FCOS-Meeting 16:34:16 we voted that the legislature could do it if they wanted but not on it directly 16:34:18 FYI Europe will switch in a couple of weeks 16:34:47 yzhang: there's something happening in BC to that effect as well 16:35:06 jlebon: dang west coast always ahead 16:35:32 #chair ajeddeloh rfairley jlebon kaeso yzhang bgilbert jbrooks kaeso 16:35:32 Current chairs: ajeddeloh bgilbert dustymabe jbrooks jlebon kaeso rfairley yzhang 16:35:37 if I missed anyone let me know 16:36:24 #topic Action items from last meeting 16:37:28 * ajeddeloh to ask echelog.com if they can log our channel 16:38:22 Its logged! 16:38:31 also #coreos for CL 16:39:06 ajeddeloh++ 16:39:08 #info ajeddeloh was able to get #fedora-coreos logged 16:39:56 and it looks like the topic in #fedora-coreos shows that 16:40:02 so we should be good 16:40:06 thanks andrew 16:40:11 ajeddeloh++ 16:41:08 #topic Add kernel and initramfs.img to the pipeline output 16:41:13 #link https://github.com/coreos/fedora-coreos-tracker/issues/161 16:41:39 we have a request to add the kernel/initrd to the output of our pipeline 16:41:55 which would make it so that people don't have to crack open the iso image if they want to do a PXE install 16:42:29 ian showed me a nice ipxe script you can use to just grab the kernel/initrd directly from the output of our pipeline 16:42:55 obviously we haven't fully investigated live PXE and live ISO use cases and what the solutions to those are going to look like 16:43:21 so those investigations/results will play in here, but in the short term does anyone see issues with adding the artifacts to the output of the pipeline? 16:43:54 bgilbert: or kaeso might have input 16:44:19 sgtm 16:44:24 seems fine to me. we'll want to teach this to coreos-assembler so it makes it in meta.json 16:44:53 right. that's where we'd implement it 16:44:59 it's like... 70M more per build? 16:45:14 sgtm, except that we may want to specify what is the initrd for 16:45:21 jlebon: yeah i wasn't worried about the size 16:45:33 sgtm 16:45:40 70M compressed? 16:45:51 my understanding is that it isn't the live-PXE one, just the installer one 16:46:04 but I may have misunderstood 16:46:07 kaeso: right 16:46:40 dustymabe: yeah sorry, my comment was to mean size shouldn't be an issue for anyone :) 16:47:05 to be clear, the end goal is to have the installer and live PXE one be the same, right 16:47:20 (and also the same as the "normal" one? 16:47:58 ajeddeloh: i honestly don't know - there is value in only having one, but there is also value in not having to download the entire OS if you are going to point it at something else 16:48:24 so still TBD 16:48:30 and up for discussion 16:49:13 so on PXE we'd have two initramfs's right? 16:49:14 #105 and #106 encompass these dtopics 16:49:24 (I'll note my comment directly in the ticket) 16:50:31 oh I was mistaken how that works 16:51:05 I mean we can have two initramfs's that both get unpacked, and the whole OS is in the second 16:51:23 have the first be uniform everywhere 16:51:34 have the second only be loaded in the case of PXE 16:52:09 ajeddeloh: maybe - I had started to look into this but then switched off to getting UEFI installs to work 16:52:21 then PXE in general (i.e . excluding live PXE) 16:52:33 and now I'm working on something else tyring to polish the installer experience 16:52:37 :) 16:52:55 so we'll have to circle back and have that discussion when I get to investigate it more 16:53:13 sure 16:53:31 any other comments for this topic ? 16:55:35 ok that's all the tmeeting topics we have 16:55:41 #topic open floor 16:55:56 feel free to add additional open floor topics to the etherpad 16:55:58 https://public.etherpad-mozilla.org/p/20190313-FCOS-Meeting 16:56:04 or just bring them up here 16:57:57 I maybe have one topic, mentioned in https://github.com/coreos/fedora-coreos-tracker/issues/83#issuecomment-467016083 16:58:33 how do nodes know about their own current update stream? 16:58:59 kaeso: i.e. options are? 16:59:04 in a file in /etc/ 16:59:19 or somehow by querying an API local to the host 16:59:37 the usual suspects, yes 16:59:40 I think jlebon and bgilbert may have discussed this recently 16:59:40 a /usr file 16:59:51 a dbus api (rpm-ostree?) 17:00:16 and os-release (or similar) 17:00:37 I'd tend to prefer that a tree knows its own stream, but that does require some post-processing when building that tree 17:00:42 if we go with stream = branch, then yeah, you could just query the branch you're on 17:01:04 I think the tricky part is at what point of the pipeline the info is injected in the OS 17:01:14 jlebon: how well does that work when rpm-ostree is being operated by the Cincinnati client? 17:01:26 consumption is probably the simpler part once we decide on a format 17:01:38 does it still know about branches, or only a commit hash? 17:02:21 we can fashion it any way we'd like, e.g. RHCOS just feeds rpm-ostree commit hashes 17:02:36 i guess the question is, where does the source of truth live, in the cincinnati client configs, or in rpm-ostree 17:02:48 right 17:02:58 jlebon: in rpm-ostree, I would say 17:04:15 hmm 17:04:27 I'm hesitant about creating the impression that Cincinnati is an optional layer on top 17:04:27 jlebon: can rpm-ostree lookup commit->branch? 17:04:44 which is perfectly okay to bypass 17:05:18 bgilbert: it is indeed only providing upgrades *hinting* 17:05:18 which is a fuzzy concern, I know 17:05:20 kaeso: not easily. though there's prior art with other ostree users embedding the branch a commit is for in the commit itself, which would make this easy 17:06:14 kaeso: i.e. I don't think we want users disabling Cincinnati and updating directly from the ref 17:07:14 we can have a middle here, where rpm-ostree knows when it's being driven by cincinnati or not 17:07:16 bgilbert: agreed, I'm not advocating for that 17:07:52 jlebon: +1 for the middle ground 17:08:12 jlebon: yep, that would be https://github.com/projectatomic/rpm-ostree/issues/1747 17:08:23 kaeso: right. but I'm wondering whether having the stream name live in rpm-ostree both 1) adds complexity and 2) pushes us closer to that direction 17:08:25 YMMV 17:09:02 however the cincinnati client (but not only that) would still need to know what's current OS stream 17:09:20 kaeso: right exactly. so we could e.g. block/make it harder to `rpm-ostree upgrade` if cincinnati is enabled, and otherwise allow it 17:10:20 bgilbert: I think I misled you, I really meant "live in the OS / rpm-ostree metadata" 17:11:48 kaeso: ah, okay 17:12:06 as a read-only property, at least 17:12:13 +1 17:12:31 we'd need a manual way to switch streams, though 17:12:52 the branch name also isn't necessarily how we want the stream to appear, it's more of an implementation detail 17:13:05 yep, but I think cincinnati can't help with switching stream 17:13:38 as it needs both source and target version to be in the same graph 17:13:50 oh. yeah 17:14:06 so we would need a graph with mixed-stream nodes inside 17:14:54 I think live-switching stream is purely a manual operation 17:15:05 we could give instructions for switching streams at the rpm-ostree level 17:15:06 yeah 17:15:07 maybe we should come up with scenarios and how we want it to feel for the user, e.g. knowing which stream you're on, how to switch streams, and how to force an upgrade 17:15:12 does someone want to summarize this discussion somewhere ? 17:15:16 so if the cincinnati only sources this information from the OS, it's even better 17:15:30 *cincinnati client 17:16:54 dustymabe: I'll do open a ticket to split this from the existing ticket 17:17:39 k 17:17:46 #action kaeso to open a ticket for node stream introspection, manual stream switching, and forced upgrades 17:17:55 thanks kaeso 17:18:03 any other topics before we break? 17:19:23 (not from me) 17:19:32 * ajeddeloh has none 17:19:51 not from me 17:20:15 #endmeeting