16:30:33 <dustymabe> #startmeeting fedora_coreos_meeting
16:30:33 <zodbot> Meeting started Wed Apr  1 16:30:33 2020 UTC.
16:30:33 <zodbot> This meeting is logged and archived in a public location.
16:30:33 <zodbot> The chair is dustymabe. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:30:33 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:30:33 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:30:38 <dustymabe> #topic roll call
16:30:42 <dustymabe> .hello2
16:30:45 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:31:05 <cyberpear> .hello2
16:31:06 <zodbot> cyberpear: cyberpear 'James Cassell' <fedoraproject@cyberpear.com>
16:31:29 <jlebon> .hello2
16:31:30 <zodbot> jlebon: jlebon 'None' <jonathan@jlebon.com>
16:31:32 <jdoss> .hello2
16:31:34 <zodbot> jdoss: jdoss 'Joe Doss' <joe@solidadmin.com>
16:33:00 <dustymabe> #chair cyberpear jlebon jdoss skunkerk
16:33:00 <zodbot> Current chairs: cyberpear dustymabe jdoss jlebon skunkerk
16:33:26 * dustymabe thinks we're missing quite a few people today
16:34:07 <jlebon> yeah, looks like :|
16:34:09 <dustymabe> kaeso[m]: bgilbert: around today?
16:34:09 <kaeso[m]> .hello lucab
16:34:10 <zodbot> kaeso[m]: lucab 'Luca Bruno' <lucab@redhat.com>
16:34:17 <dustymabe> \o/ - yay
16:34:29 <jlebon> (i almost didn't make it myself; just had a super long meeting right before this :) )
16:34:31 <dustymabe> welcome back kaeso[m] ! you've been missed
16:34:45 <dustymabe> #chair kaeso[m]
16:34:45 <zodbot> Current chairs: cyberpear dustymabe jdoss jlebon kaeso[m] skunkerk
16:35:05 <dustymabe> #topic Action items from last meeting
16:35:26 <dustymabe> no action items from last meeting - woot!
16:35:36 <dustymabe> #topic news
16:36:01 <dustymabe> #info we came out with a testing release last week that moved us to using networkmanager in the initrd
16:36:28 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/394
16:36:41 <lorbus> .hello2
16:36:42 <zodbot> lorbus: lorbus 'Christian Glombek' <cglombek@redhat.com>
16:36:43 <dustymabe> that build introduced a regression on some cloud platforms
16:36:59 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/440
16:37:30 <skunkerk> .hello sohank2602
16:37:31 <zodbot> skunkerk: sohank2602 'Sohan Kunkerkar' <skunkerk@redhat.com>
16:37:34 <jlebon> dustymabe: nice work on pushing the NM work all the way through!
16:37:38 <dustymabe> #info we put out another testing release yesterday (31.20200323.2.1) that fixed the regression
16:37:46 <dustymabe> thanks jlebon
16:37:52 <dustymabe> #chair lorbus
16:37:52 <zodbot> Current chairs: cyberpear dustymabe jdoss jlebon kaeso[m] lorbus skunkerk
16:38:14 <dustymabe> the NM in initrd work should land in next week's stable release
16:38:39 <dustymabe> #info please test out the latest testing release to test NM in the initrd well before we release it to stable in one week
16:38:58 <dustymabe> ok i'll move on to meeting itmes
16:39:05 * dustymabe can't spell today
16:39:07 <dustymabe> #topic
16:39:11 <dustymabe> #undo
16:39:11 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7fe002258a10>
16:39:39 <dustymabe> #topic Missing libsss_sudo
16:39:45 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/445
16:40:06 <dustymabe> this one was just opened today but it seems like it's worth a quick look
16:40:41 <dustymabe> jlebon: do you know if the user's proposed solution is the right thing to do (i.e. is just including that package sufficient) ?
16:41:04 <jlebon> it seems reasonable, yes
16:41:28 <dustymabe> ok, the other question is - is this something we'd want to do in the base ?
16:41:44 <jlebon> we already ship sssd. i would've expected that plugin to already be there
16:41:50 <dustymabe> or relegate to https://github.com/coreos/fedora-coreos-tracker/issues/401
16:42:32 <dustymabe> ok, so this is more along the lines of "oops, that should have been included already" ?
16:43:16 <jlebon> i think so, but interested in other opinions
16:43:31 <jlebon> i haven't used sssd much myself
16:44:04 <dustymabe> anyone else have an opinion here?
16:44:07 <bgilbert> .hello2
16:44:08 <zodbot> bgilbert: bgilbert 'Benjamin Gilbert' <bgilbert@backtick.net>
16:44:12 <dustymabe> #chair bgilbert
16:44:12 <zodbot> Current chairs: bgilbert cyberpear dustymabe jdoss jlebon kaeso[m] lorbus skunkerk
16:44:28 <dustymabe> or "no opinion" :)
16:45:19 <kaeso[m]> I was checking the package content earlier today, and I think it's just a small .so which we could ship
16:45:39 <jlebon> FWIW, it's on silverblue at least by default :)
16:46:04 <dustymabe> it sounds like it was also in CL
16:46:18 <cyberpear> I haven't used that plugin, but it seems reasonable to include, assuming not many deps
16:46:19 <lorbus> size is ~40kB, voting to include :)
16:46:36 <cyberpear> +1 from me for including
16:47:15 <dustymabe> #proposed This fucntionality provided by libsss_sudo is missing functionality that we should include by default. The fact that it is currently missing was an oversight.
16:47:34 <dustymabe> i'm lukewarm on that second sentence
16:48:05 <jlebon> yeah, i think i'm more "lean towards including it, but defer to sssd SMEs"
16:48:05 <dustymabe> and I'll spell better in the #agreed
16:48:47 <dustymabe> jlebon: that implies we would need to ask another team?
16:49:04 <dustymabe> or just wait for somebody who knows better to come along?
16:49:11 <kaeso[m]> I'd ask for a sample fcct snippet in exchange, as I have no idea how it can be configured via Ignition
16:49:12 <jlebon> dustymabe: i meant more the latter, but the former works too
16:49:40 <dustymabe> jlebon: is it a strong enough reason to include it if CL had it?
16:49:50 <dustymabe> anybody have CL booted up right now?
16:50:20 <jlebon> IOW, it *seems* like obvious missing functionality we want
16:50:26 <jlebon> dustymabe: probably, yeah
16:51:27 <dustymabe> #proposed The functionality provided by libsss_sudo appears to be missing functionality that we want in FCOS. We are leaning towards including it in the base unless good reasoning for not doing so surfaces.
16:51:45 <jlebon> +1
16:51:49 <dustymabe> ack/nack?
16:52:18 <dustymabe> kaeso[m]: we can also ask for the sample fcct
16:52:21 <bgilbert> +1
16:52:37 <cyberpear> I use sssd, but not this plugin. +1 to #proposed, +1 to asking for snippet.
16:53:35 <kaeso[m]> +1
16:53:44 <cyberpear> I think it'd be good to collect use cases and fcct samples whenever we add a package
16:53:54 <dustymabe> #agreed The functionality provided by libsss_sudo appears to be missing functionality that we want in FCOS. We are leaning towards including it in the base unless good reasoning for not doing so surfaces.
16:54:08 <dustymabe> ok I'll update the ticket with this after the meeting
16:54:28 <dustymabe> #topic Don't bring up networking in the initramfs on first boot by default
16:54:36 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/443
16:55:14 <jlebon> ahh yup, i can expand on this
16:55:35 <jlebon> (libsss_sudo.so is 24kb btw, no other deps)
16:56:12 <jlebon> so, now we have the live ISO and promoting it one of the primary paths for doing bare metal installs
16:57:10 <jlebon> it works great, but it doesn't mesh well with the network configuration UX we want
16:57:53 <jlebon> right now the live ISO matches all the other FCOS deliverables and try to bring up networking during the initrd
16:58:16 <jlebon> this is an issue if part of your install process *is* to set up networking on the bare metal machine
16:58:50 <jlebon> so we have a primary goal to break that cycle
16:59:01 <jlebon> however, there's a higher-level issue here
16:59:21 <jlebon> which is that the only reason we bring up networking in the initrd is because ignition *may* require it to fetch resources
16:59:56 <dustymabe> jlebon: right. so we have a more narrowly scoped issue about not requiring network to boot the Live ISO (presumably for an install): https://github.com/coreos/fedora-coreos-tracker/issues/349
17:00:00 <jlebon> so a bigger win is to fix that instead by only bringing up networking when it's required
17:00:28 <dustymabe> what you're talking about is to solve this problem more generically, not just for the live ISO
17:00:44 <dustymabe> and have network only be brought up in the initramfs if it's needed?
17:00:54 <jlebon> this is not really a big difference really for most cloud images, since they majority of them definitely always need networking for ignition to even fetch its config
17:01:45 <jlebon> but e.g. qemu, vmware, s390x, and of course the live ISO for example don't inherently need networking
17:02:29 <jlebon> so the approach we're suggesting is to (1) provide an easy fix to get the live ISO working offline, and (2) fix the general problem long-term
17:03:24 <dustymabe> +1
17:03:44 <dustymabe> I have a short term fix for the live ISO in https://github.com/coreos/fedora-coreos-config/pull/326
17:04:38 <jlebon> one might say "meh, who cares about qemu always needing networking", but i for one think it'd be really nice to be able to take FCOS for a spin entirely offline
17:05:18 <jlebon> it also fixes the live ISO path more correctly, since one actually *may need* networking if the embedded ignition config has remote resources
17:06:04 <dustymabe> anyone have any qeustions/concerns for jlebon?
17:06:15 <cyberpear> (on subsequent boots, does initrd do net?)
17:06:27 <jlebon> (no, that doesn't change)
17:06:40 <dustymabe> (hehe)
17:07:09 <bgilbert> cyberpear: not currently.  but there are cases in the future where it might need to
17:07:16 <bgilbert> e.g. cryptroot
17:07:39 <dustymabe> bgilbert: right, that would probably be case by case, though, right?
17:07:42 <bgilbert> yup
17:07:46 <dustymabe> +1
17:07:47 <jlebon> right.  essentially, whatever needs networking needs to declare it
17:07:54 <cyberpear> right, clevis etc
17:08:12 <jlebon> this issue is specifically about ignition only declaring it when it needs it
17:09:25 <dustymabe> thanks jlebon for bringing this up. seems like a reasonable idea and a good thing to do long term. maybe let's carry on the discussion in the ticket?
17:09:33 <jlebon> yup, +1
17:09:51 <dustymabe> #topic Publish the initrd and rootfs images separately for PXE booting
17:09:58 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/390
17:10:49 <bgilbert> so we talked about this a few weeks ago
17:10:57 <jlebon> bgilbert: re. https://github.com/coreos/fedora-coreos-tracker/issues/390#issuecomment-605370179 is this something about iPXE itself, or the link was just bad?
17:11:01 <jlebon> ahh sorry
17:11:15 <bgilbert> dustymabe asked me to bring it up again, because of one new data point:
17:11:59 <bgilbert> I did some work on iPXE-booting FCOS on Packet, and indeed, iPXE takes takes ~5 minutes to fetch the initrd over HTTPS from our release bucket
17:12:12 <bgilbert> I did not try HTTP, though I wonder whether that would help
17:12:23 <bgilbert> depending how bad the iPXE crypto implementation is
17:13:02 <bgilbert> I don't think it changes my view on the problem, but FWIW.  /shrug
17:13:02 <dustymabe> i'm not going to lie it's taking me several minutes to download a qcow from our bucket before (just curl on my laptop) - is this iPXE or is it the remote ?
17:13:06 <jlebon> asking the same question again: to sanity-check, we're sure this is about iPXE sucking at HTTPS and not just the connection being slow, right?
17:13:25 <bgilbert> we are not
17:13:30 <jlebon> there's also cloudfront
17:13:42 <bgilbert> if we want to run more comprehensive tests, we certainly can
17:13:47 <bgilbert> but in any event it's not a one-off
17:14:03 <dustymabe> +1 for more testing
17:14:16 <dustymabe> if it's the remote then it won't matter what we do
17:14:54 <dustymabe> maybe we could work with the packet people to place a file in their infra and see how long it takes then
17:16:06 <dustymabe> anyone opposed to asking for more testing on this?
17:16:21 <jlebon> so essentially: (1) do more testing to sanity check the current approach is viable, then (2) if it's viable, go ahead with splitter tool
17:16:50 <dustymabe> (1) do more testing to make sure it's not the remote server that is causing the slowdown
17:17:01 <dustymabe> (2) we'd need to re-evaluate probably
17:17:13 <bgilbert> dustymabe: +1
17:17:22 <dustymabe> because we'd kind of want iPXE from packet to just work against our published artifacts
17:17:23 <jlebon> i think we're saying the same thing :)
17:17:35 <dustymabe> +1
17:18:02 <dustymabe> #info we'll do more testing for #390 to see if it's the remote server causing the slowdown or actually a slowdown in iPXE
17:18:31 <dustymabe> #topic Booting on OpenStack does not retrieve SSH keys from MD service
17:18:36 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/422
17:18:45 <dustymabe> cyberpear: I think you opened this issue
17:18:57 <cyberpear> yes
17:19:22 * dustymabe will let cyberpear frame the topic
17:20:32 <cyberpear> every "cloud image" for other OSes I've found supports the MD service on OpenStack, same as on ec2, etc
17:20:50 <cyberpear> FCOS image does not, unless you pass special cmdline options
17:21:25 <cyberpear> ubuntu, fedora, RHEL, CentOS, and probably CL, but I didn't actually test CL on OpenStack
17:21:50 <cyberpear> "how hard would it be to automatically detect the MD service?"
17:22:06 <jlebon> hmm, i wonder if https://github.com/coreos/ignition/issues/903 could help here
17:22:08 <dustymabe> is the problem that we have a single openstack image but two possibly places where metadata could come from?
17:22:35 <dustymabe> cc kaeso[m]
17:22:49 <jlebon> basically instead of doing the same hack as ignition to opportunistically try, have afterburn key off of what ignition found out
17:22:49 <cyberpear> I don't know how non-MD supporting OpenStack installs otherwise provide MD, but maybe someone here knows?
17:23:14 <jlebon> via a config drive
17:23:22 <jlebon> for ignition user-data
17:23:26 <bgilbert> it's not a question of whether it's hard, it's a question of whether it's safe
17:23:41 <cyberpear> why is it safe for Fedora to do it, but not for us?
17:23:54 <cyberpear> and RHEL?
17:24:03 <kaeso[m]> CL has the same behavior as FCOS. The user flow would be to write (via Ignition) a systemd dropin  to specify the openstack-flavor.
17:24:04 <bgilbert> just because other people are doing it doesn't mean that it's safe :-)
17:24:19 <bgilbert> it's harder to justify different behavior between Ignition and Afterburn though
17:24:35 <jlebon> bgilbert: ignition goes against that argument too though
17:24:40 <bgilbert> jlebon: yup
17:24:55 <jlebon> WDYT about keying off of ignition here?
17:24:56 <dustymabe> so does ignition try to fetch from either source today?
17:25:07 <dustymabe> but afterburn doesn't ?
17:25:33 <jlebon> that way, the discovery is centralized in ignition and it and afterburn are consistent between each other
17:25:45 <kaeso[m]> Afterburn updates ssh keys on each boot though
17:25:47 <bgilbert> last time we discussed this internally, we were going to talk to OpenStack folks about whether in 2020 we can just assume a metadata service exists
17:26:48 <kaeso[m]> I would be in favor of updating the baseline so that platform `openstack` actually means "an openstack platform with a metadata endpoint"
17:26:49 <jlebon> bgilbert: is the metadata service part of swift?
17:27:15 <cyberpear> I don't think it is
17:27:16 <kaeso[m]> that means dropping some code from Ignition though, I guess
17:27:17 <jlebon> because we did recently have an ask to be able to support swiftless openstack :)
17:27:37 <dustymabe> kaeso[m]: right, it might be more approprate to flip the default to metadata and have users who want to use the configdrive source to add the configuration?
17:27:37 <bgilbert> nova-api or nova-api-metadata
17:27:41 <cyberpear> (my OpenStack doesn't have swift, but does have Ceph which might be providing something similar)
17:27:50 <jlebon> ok, ack
17:28:12 <jlebon> when was the metadata service introduced?
17:28:28 <jlebon> i'd definitely be in favour of shedding the config drive code if feasible
17:28:44 <dustymabe> jlebon: one step in that direction is to change the default
17:28:58 <bgilbert> from looking at the docs real quick, it appears that the service is still optional
17:29:34 <jlebon> dustymabe: there is no default today though :)
17:29:47 <dustymabe> jlebon: oh? you have to configure afterburn either way?
17:30:06 <bgilbert> dustymabe: that's what we're discussing
17:30:09 * cyberpear is +1 for swiftless OpenStack support (it's my current blocker for OKD on OpenStack)
17:30:15 <bgilbert> afterburn doesn't support config-drive and needs to be told to use metadata
17:30:26 <dustymabe> hmm ok
17:30:45 <dustymabe> so the "harm" here is that afterburn would run and not reach the metadata service?
17:31:02 <jlebon> or reach some other node on the network
17:31:25 <dustymabe> where that node happened to be using the same network that the metadata service usually ran as
17:31:26 <jlebon> which can provide whatever metadata it wants, even though it's not "the" metadata server
17:31:31 <bgilbert> pull SSH keys from some node that acquired that particular link-local IP
17:31:49 <dustymabe> but that is a problem for every other cloud distro already
17:31:56 <dustymabe> as cyberpear mentioned
17:32:27 <kaeso[m]> wait, but OKD/OCP anyway are not supposed to pull SSH keys from the cloud
17:32:30 <dustymabe> IOW, yes that's a problem but is it one we really need to worry about
17:32:48 <bgilbert> dustymabe: I'd be in favor of making good decisions, not typical ones :-)  but I agree that the current situation isn't really tenable
17:32:49 <cyberpear> (If some node has 169.254.169.254 address, such network is broken IMO)
17:32:59 <bgilbert> cyberpear: why?
17:33:12 <bgilbert> nodes can pick their own link-local addresses
17:33:57 <jlebon> right.  so my suggestion is make afterburn key off of ignition, so at least we're consistent.  but also ask the openstack devs if it's unreasonable nowadays to not support config drive anymore
17:34:24 <dustymabe> jlebon: so we'd need to find some way for ignition to write out a file that afterburn can then key off of on every boot
17:34:33 <dustymabe> since it runs on every boot
17:34:33 <cyberpear> bgilbert: it'd only be a problem in the case w/ MD but w/o DHCP
17:34:53 <cyberpear> w/ DHCP, the link-local address wouldn't be routabel
17:35:00 <kaeso[m]> jlebon: something like `/var/lib/ignition/providers/openstack/metadata` and `/config-drive`?
17:35:27 <bgilbert> cyberpear: it's not a question of routability.  it's a security vulnerability to allow a random node on the same network segment to inject SSH keys into instances.
17:35:46 * dustymabe notes we're running over time, but do think this discussion is currently productive
17:36:12 <jlebon> dustymabe, kaeso[m]: i linked to https://github.com/coreos/fedora-coreos-tracker/issues/390 earlier since it might help, but maybe not either since we want something more permanent
17:36:24 <cyberpear> bgilbert: is there a better solution? -- Do we convince the OpenStack folks to support the qemu way of passing ign?
17:36:40 <cyberpear> via firmware_cfg?
17:36:55 <bgilbert> heh, well, fw_cfg is itself controversial
17:37:07 <cyberpear> (since most non-VMware OpenStack is just qemu-kvm in the end)
17:37:32 <bgilbert> I'd personally prefer the metadata service to be mandatory but I get why that may not be possible
17:37:35 <dustymabe> do we want to end the discussion here and investigate the "queue off of ignition" route ?
17:37:35 <jlebon> i think introducing another way to get metadata is counter productive :)
17:38:09 <dustymabe> sigh - i think I used the wrong word
17:38:13 <bgilbert> jlebon dustymabe: FWIW I don't think keying off Ignition is useful
17:38:20 <cyberpear> Maybe someone can ask Red Hat security folks to evaluate it for the RHEL case, and we can inherit their solution?
17:38:28 <dustymabe> s/queue/cue/
17:38:36 <bgilbert> as long as Ignition unconditionally tries metadata, the horse has left the barn
17:38:46 <bgilbert> and IMO Afterburn might as well do the same thing
17:39:02 <dustymabe> bgilbert: so you think we should change Ignition to not do that?
17:39:10 <kaeso[m]> cyberpear: RHEL (RHCOS really) does no use cloud ssh keys at all, this is for FCOS really
17:39:10 * dustymabe assumes Ignition currently does that
17:39:28 <cyberpear> kaeso[m]: it does use MD for ign, doesn't it?
17:39:34 <dustymabe> RHEL does, RHCOS doesn't
17:39:37 <jlebon> bgilbert: that's my point though. if we're going to auto-discover, at least we should auto-discover once only
17:39:57 <jlebon> so we're sure whatever we settled on is what we roll with
17:40:27 <jlebon> that's entirely separate from whether we should auto-discover in the first place, which i agree we shouldn't
17:40:34 <bgilbert> jlebon: sigh.  yes... but also it's another piece of state we're talking about having Ignition write out
17:40:34 <kaeso[m]> I think jlebon's one is a reasonable improvement
17:41:27 <kaeso[m]> bgilbert: are you thinking about re-running Ignition cases?
17:42:07 <bgilbert> kaeso[m]: no, I'm just worried about the pressure on Ignition to write out all sorts of flags and internal state.  it's growing tendrils into all parts of the system
17:42:09 <jlebon> bgilbert: yeah... that's why i alluded to https://github.com/coreos/ignition/issues/903 earlier
17:42:57 <jlebon> i.e. let's not have ignition write 10 separate state files
17:43:08 <bgilbert> well, sure
17:43:19 <kaeso[m]> the least resistance path is to write FCOS docs / fcct sugar to write the systemd dropin
17:43:20 <bgilbert> it's becoming too tightly coupled, is my point
17:43:40 <jlebon> bgilbert: yeah, i don't disagree :(
17:44:18 <dustymabe> i'm going to try a proposal
17:44:29 <jlebon> FWIW, git master cloud-init still has the configdrive code btw
17:44:31 <dustymabe> i'm not going to get offended if it gets shot down
17:44:39 <dustymabe> #proposed we'd like to solve this itch. Ignition already does auto-discovery of the metadata service. We should investigate the feasibility of having Afterburn key off of Ignition's discovery
17:45:08 * dustymabe should mention openstack somewhere in there
17:45:28 <cyberpear> +1
17:45:34 <dustymabe> if this is not what we want we can punt to next meeting or whatever, I know some of us probably need to leave soon
17:45:42 <cyberpear> "OpenStack metadata service"?
17:45:47 <bgilbert> #proposed Modify Afterburn to read from the metadata service by default.  Document that Afterburn requires the metadata service (or implement config-drive support).
17:46:08 <bgilbert> ...since Ignition already gives a chance for 169.254.169.254 to compromise the system
17:46:24 <dustymabe> I'm fine with that bgilbert
17:46:37 <bgilbert> dustymabe: I think it's feasible, I just think we shouldn't keep adding flags'n'such to Ignition
17:46:53 <jlebon> how hard would it be to add config-drive support?
17:47:07 <jlebon> i suspect not very
17:47:28 <dustymabe> to afterburn?
17:47:34 <jlebon> yeah
17:47:36 <bgilbert> I think not very
17:47:44 <bgilbert> kaeso[m]: thoughts on the proposals?
17:47:49 <jlebon> basically, if we're doomed to support both, then let's support both
17:47:52 <dustymabe> if it was go then we could just copy the ignition code probably
17:48:13 <kaeso[m]> it depends on the format, ibmcloud has 3x similar "ssh keys on config drive" and they go from "very simple" to "who came up with this"
17:48:32 <jlebon> hehe
17:48:44 <kaeso[m]> bgilbert: so basically aliasing openstack-metadata to openstack in afterburn?
17:48:48 <bgilbert> yeah
17:49:02 <jlebon> ohhhh there's one key difference btw between ignition and afterburn
17:49:30 <jlebon> if it's config-drive, then afterburn can assume that it's already ready and available because ignition must've gotten it from there too
17:49:48 <bgilbert> not on subsequent boots
17:49:51 <jlebon> so afterburn would be more of a "check config-drive first, then fall back to metadata server"
17:49:51 <bgilbert> but it does run much later, so
17:50:01 <bgilbert> more time for the config-drive to settle
17:50:22 <jlebon> hmmm, true. but right, yeah
17:50:27 <kaeso[m]> jlebon: it can still do even without Ignition, yes
17:50:50 <jlebon> ok, that makes me feel better
17:51:02 <jlebon> (re. not hard binding the two)
17:51:05 <dustymabe> #proposed Modify Afterburn to read from the metadata service by default.  Document that Afterburn requires the  metadata service. Later possibly add support for config drive and update documentation
17:51:22 <kaeso[m]> so basically 1) wire the `openstack` platform id 2) if no config-drive found, fetch from metadata
17:51:45 <dustymabe> ack/nack?
17:51:54 <jlebon> dustymabe: i think i want something more like kaeso[m]'s proposal :)
17:52:07 <dustymabe> where is that proposal?
17:52:48 <jlebon> #proposed modify afterburn to only know about `openstack` and in that mode, read from the config drive first then fallback to fetch from metadata server
17:53:37 <cyberpear> +1
17:53:42 <dustymabe> right, that's pretty much what i was proposing but doesn't require config drive support to exist before we fix the problem
17:53:53 <kaeso[m]> ack
17:53:55 <dustymabe> +1
17:54:00 <cyberpear> seems like the best long-term solution
17:54:03 <bgilbert> +1
17:54:19 <dustymabe> #agreed modify afterburn to only know about `openstack` and in that mode, read from the config drive first then fallback to fetch from metadata server
17:54:24 <jlebon> dustymabe: the config-drive bit is key though because it helps ensure it matches ignition
17:54:28 <kaeso[m]> it's more like "use metadata if there is no config-drive though"
17:54:33 <dustymabe> +1
17:54:38 <dustymabe> #topic open floor
17:54:42 <kaeso[m]> *" though
17:54:45 <dustymabe> I really apologize if anyone has been waiting for this
17:54:52 <dustymabe> anything for open floor?
17:55:00 <bgilbert> the latest release of the testing stream now has a DigitalOcean image
17:55:07 <bgilbert> and the next stable release will have one also
17:55:12 <dustymabe> #info the latest release of the testing stream now has a DigitalOcean image
17:55:22 <bgilbert> this is suitable for the DigitalOcean "custom image" flow
17:55:26 <dustymabe> bgilbert: we should probably add a docs page to show people how to use it
17:55:27 <bgilbert> i.e. users will need to upload it themselves
17:55:30 <bgilbert> dustymabe: +1
17:55:46 <jlebon> nice!
17:55:46 <bgilbert> DigitalOcean can't ship FCOS directly to users yet because that requires more technical work on our end
17:55:54 <bgilbert> (custom images get DHCP, standard images don't)
17:56:00 <dustymabe> #undo
17:56:00 <zodbot> Removing item from minutes: INFO by dustymabe at 17:55:12 : the latest release of the testing stream now has a DigitalOcean image
17:56:07 <dustymabe> #info the latest release of the testing stream now has a DigitalOcean "custom image"
17:56:12 <jlebon> (i find that different intriguing)
17:56:18 <jlebon> s/different/difference/
17:56:51 <dustymabe> will close out meeting in 60 seconds
17:56:54 <jlebon> bgilbert++
17:56:54 <zodbot> jlebon: Karma for bgilbert changed to 4 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:57:57 <dustymabe> #endmeeting