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