16:30:14 <dustymabe> #startmeeting fedora_coreos_meeting
16:30:14 <zodbot> Meeting started Wed Feb 13 16:30:14 2019 UTC.
16:30:14 <zodbot> This meeting is logged and archived in a public location.
16:30:14 <zodbot> The chair is dustymabe. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:30:14 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:30:14 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:30:20 <ajeddeloh> .hello2
16:30:20 <dustymabe> #topic roll call
16:30:22 <zodbot> ajeddeloh: ajeddeloh 'Andrew Jeddeloh' <andrew.jeddeloh@redhat.com>
16:30:26 <yzhang> .hello2
16:30:26 <dustymabe> .hello2
16:30:26 <zodbot> yzhang: yzhang 'Yu Qi Zhang' <jzehrarnyg@gmail.com>
16:30:30 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:30:32 <mnguyen_> .hello mnguyen
16:30:33 <zodbot> mnguyen_: mnguyen 'Michael Nguyen' <mnguyen@redhat.com>
16:30:35 <rfairley> .hello2
16:30:36 <zodbot> rfairley: rfairley 'None' <rfairley@redhat.com>
16:31:09 <bgilbert> .hello2
16:31:10 <zodbot> bgilbert: bgilbert 'Benjamin Gilbert' <bgilbert@backtick.net>
16:31:21 <lorbus[m]> .hello lorbus
16:31:22 <zodbot> lorbus[m]: lorbus 'Christian Glombek' <cglombek@redhat.com>
16:31:29 <walters> .hello2
16:31:30 <zodbot> walters: walters 'Colin Walters' <walters@redhat.com>
16:31:42 <dustymabe> #chair ajeddeloh yzhang mnguyen_ rfairley lorbus[m] bgilbert walters
16:31:42 <zodbot> Current chairs: ajeddeloh bgilbert dustymabe lorbus[m] mnguyen_ rfairley walters yzhang
16:32:43 <ksinny> .hello sinnykumari
16:32:44 <zodbot> ksinny: sinnykumari 'Sinny Kumari' <ksinny@gmail.com>
16:34:07 <kaeso_> .hello lucab
16:34:08 <zodbot> kaeso_: lucab 'Luca Bruno' <lucab@redhat.com>
16:34:12 <dgilmore> hi dustymabe
16:34:17 <dustymabe> #chair ksinny kaeso_ dgilmore
16:34:17 <zodbot> Current chairs: ajeddeloh bgilbert dgilmore dustymabe kaeso_ ksinny lorbus[m] mnguyen_ rfairley walters yzhang
16:34:20 <dustymabe> welcome all
16:34:30 <lorbus[m]> o/
16:34:46 <dbenoit> .hello2
16:34:48 <zodbot> dbenoit: dbenoit 'David Benoit' <dbenoit@redhat.com>
16:34:59 <dustymabe> #topic Action items from last meeting
16:35:01 <sanja> .hello2
16:35:02 <zodbot> sanja: sanja 'Sanja Bonic' <sanja@redhat.com>
16:35:10 <dustymabe> #chair sanja dbenoit
16:35:10 <zodbot> Current chairs: ajeddeloh bgilbert dbenoit dgilmore dustymabe kaeso_ ksinny lorbus[m] mnguyen_ rfairley sanja walters yzhang
16:35:18 <dustymabe> #chair lorbus[m]
16:35:18 <zodbot> Current chairs: ajeddeloh bgilbert dbenoit dgilmore dustymabe kaeso_ ksinny lorbus[m] mnguyen_ rfairley sanja walters yzhang
16:35:30 <dustymabe> welcome all - we had no action items from last meeting :)
16:35:34 <sanja> ./wave
16:35:40 <jlebon> .hello 2
16:35:41 <zodbot> jlebon: Sorry, but you don't exist
16:35:43 <jlebon> .hello2
16:35:44 <zodbot> jlebon: jlebon 'None' <jonathan@jlebon.com>
16:35:48 <dustymabe> #chair jlebon
16:35:48 <zodbot> Current chairs: ajeddeloh bgilbert dbenoit dgilmore dustymabe jlebon kaeso_ ksinny lorbus[m] mnguyen_ rfairley sanja walters yzhang
16:35:53 <dustymabe> jlebon: you do exist!
16:36:00 <jlebon> \o/
16:36:11 <jlebon> zodbot can be harsh sometimes
16:36:19 <dustymabe> https://imgur.com/gallery/3SnIGW5
16:36:25 <ajeddeloh> zodbot has my favorite error messages
16:36:33 <dustymabe> zodbot++
16:36:36 <dgilmore> .fire zodbot
16:36:36 <zodbot> adamw fires zodbot
16:36:36 <lorbus[m]> echo $GOPATH
16:36:42 <dustymabe> .hire zodbot
16:36:42 <zodbot> adamw hires zodbot
16:36:53 <dustymabe> ok moving on to meeting tickets
16:36:53 <rfairley> haha
16:36:54 <lorbus[m]> ahh wrong window :P
16:36:57 <strigazi> .hello2
16:36:58 <zodbot> strigazi: strigazi 'Spyros Trigazis' <strigazi@gmail.com>
16:37:01 <dustymabe> #chair strigazi
16:37:01 <zodbot> Current chairs: ajeddeloh bgilbert dbenoit dgilmore dustymabe jlebon kaeso_ ksinny lorbus[m] mnguyen_ rfairley sanja strigazi walters yzhang
16:37:03 <dustymabe> welcome!
16:37:24 <dustymabe> #topic Fedora CoreOS preview release
16:37:28 <lorbus[m]> nice turnout today! :)
16:37:31 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/145
16:37:47 <bgilbert> okay, so
16:38:12 <bgilbert> we're building a new distro with a lot of new parts
16:38:19 <miabbott> .hello miabbott
16:38:20 <bgilbert> and with some existing parts configured in new ways :-)
16:38:20 <zodbot> miabbott: miabbott 'Micah Abbott' <miabbott@redhat.com>
16:38:55 <bgilbert> it didn't seem like a great idea to release the first version of the distro and immediately suggest that people migrate production workloads to it.
16:39:06 <bgilbert> there will be bugs.  there will be things we missed.
16:39:12 <bgilbert> there will be use cases we forgot to account for.
16:39:42 <bgilbert> so: the proposal is to have FCOS be in "preview" for ~ the F30 timeframe.
16:40:09 <dgilmore> bgilbert: proposal seems sane
16:40:17 * dustymabe has discussed this with bgilbert previously and agree
16:40:21 <lorbus[m]> Q: do we not yet whether F30 timeframe will be 6mo or 1y?
16:40:22 <bgilbert> "preview" means: 1) don't use this in production workloads, 2) probably not everything will work perfectly, 3) some functionality may be missing.
16:40:28 <jbrooks> .fas jasonbrooks
16:40:29 <zodbot> jbrooks: jasonbrooks 'Jason Brooks' <jbrooks@redhat.com>
16:40:39 <dustymabe> lorbus[m]: F30 will be 6mo
16:40:50 <bgilbert> 4) we probably want to reserve the right to make breaking changes.
16:41:02 <lorbus[m]> dustymabe: thanks, I didn't follow along that discussion
16:41:10 * dgilmore wonders on multi-arch, would that be a reason to continue AtomicHost a little longer if we can not get the bits in place for CoreOS
16:41:19 <bgilbert> this also lets us test the F30 -> F31 transition without expectations of production-level stability.
16:41:30 <dustymabe> dgilmore: current proposal is to keep releasing F29AH until F29 EOL
16:41:42 <dustymabe> so two week releases of F29AH
16:41:50 <dustymabe> so no new work there
16:41:50 <bgilbert> we transition to F31, then probably wait a bit, then declare FCOS stable.
16:41:53 <dgilmore> dustymabe: sure.
16:42:03 <bgilbert> then, ~6 months later, we EOL Container Linux.
16:42:42 <bgilbert> so "stable" comes with "please start migrating your production workloads".
16:42:58 <bgilbert> we'd want to try to nail down a more concrete timeline for that EOL, at least
16:43:05 <ajeddeloh> SGTM, I'm generally in favor
16:43:10 <jlebon> i like it
16:43:12 <lorbus[m]> +1
16:43:46 <dustymabe> jbrooks: strigazi ^^ WDYT?
16:43:55 <ksinny> +1
16:44:01 <miabbott> it's a good plan; i'm just going to wonder aloud if it is going to be preview in F30 and we are already producing artifacts out of the pipeline, why not make it preview *now*?
16:44:35 <dustymabe> miabbott: we've still got to work out a lot of stuff with fedora releng first
16:44:40 <bgilbert> miabbott: to me, "preview" implies that we want users to start trying out the OS and giving us feedback
16:44:43 <dustymabe> a few of us had a meeting this morning with them
16:45:00 <bgilbert> miabbott: the OS images don't yet "look like FCOS" in some sense
16:45:16 <dustymabe> and various pieces like "signed checksums" don't exist
16:45:21 <bgilbert> miabbott: e.g., we don't have update gating or reboot coordination
16:45:35 <bgilbert> dustymabe is giving the infra-side answer and I'm giving the user-side answer :-)
16:45:45 <miabbott> i appreciate both sides of the story  :)
16:45:49 <dustymabe> which one of us is bad cop?
16:45:55 <dustymabe> :)
16:46:30 <bgilbert> also I'd want to have images built and uploaded for the major clouds
16:46:40 <bgilbert> not strictly necessary in all cases, but useful
16:47:11 <dustymabe> miabbott: did we convince you ?
16:47:16 <miabbott> i'm just thinking we have a lot of folks asking for access to FCOS already...we could point them at these early artifacts (warts and all) and have them give us VERY early feedback
16:47:40 <miabbott> dustymabe: i'm not going to argue that we change the plan you folks have come up with
16:47:46 <ajeddeloh> I think thats orthagonal to this
16:47:51 <dustymabe> if someone asks us directly I have been pointing them at the output artifacts
16:47:59 <dustymabe> but with a disclaimer
16:48:03 <ajeddeloh> We just _really_ shouldn't call it preview
16:48:19 <bgilbert> miabbott: I agree with ajeddeloh, and also honestly I think broader feedback is generally premature here
16:48:20 <ajeddeloh> super_nightly_developer_edition?
16:48:23 <miabbott> the reasoning is solid around your plans...i'm just being a persistent nag  :)
16:48:37 <dustymabe> good ol miabbott :)
16:48:41 <lorbus[m]> miabott++
16:48:50 <lorbus[m]> miabbott++
16:48:51 <bgilbert> miabbott++
16:48:51 <zodbot> bgilbert: Karma for miabbott changed to 4 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:49:01 <sanja> miabbott++
16:49:01 <bgilbert> wait, it works when I do it?
16:49:01 <zodbot> sanja: Karma for miabbott changed to 5 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:49:18 <bgilbert> rate-limited karma?  cool cool
16:49:26 <lorbus[m]> zod's got a temper sometimes
16:49:36 <dustymabe> ok - please leave feedback in the ticket - going to move on to the next topic since we have several
16:49:43 <dustymabe> and I'll *try* to leave time for open floor
16:49:46 <lorbus[m]> miabbott++
16:49:56 <miabbott> so the take away is:  if we have a motivated user (that we trust?), we'll give them access to the super perview builds
16:49:58 <dustymabe> lorbus[m]: it's because your IRC nick isn't in FAS
16:50:07 <bgilbert> ahhh
16:50:09 <dustymabe> you have a [m] in your name
16:50:13 <lorbus[m]> ha! thanks
16:50:20 <bgilbert> yeah, the builds aren't a secret or anything
16:50:22 <dustymabe> miabbott: if we have a motivated user, yes
16:50:28 <dustymabe> I don't think we have to trust them :)
16:50:31 <miabbott> ok, sounds good.  thanks folks!
16:50:32 <bgilbert> they're just... not really FCOS yet
16:50:47 <dustymabe> #topic Keep/Remove Python dependent package: setools-console
16:50:54 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/122
16:51:26 <dustymabe> I think the question is: Do we need these three utilities in FCOS
16:51:28 <dustymabe> /usr/bin/sediff
16:51:30 <dustymabe> /usr/bin/seinfo
16:51:32 <dustymabe> /usr/bin/sesearch
16:51:40 <dustymabe> if not then we can shed setools-console (another python dep)
16:52:08 <kaeso_> aren't RPM post-install scripts depending on those?
16:52:08 <dustymabe> walters: ^^ i was interested in your thoughts there
16:52:50 <walters> i haven't used those myself much; could probably coax things to run from a toolbox
16:52:55 <ajeddeloh> In a system where everything *just works* then we don't. The underlying questions are: Are these needed for debugging or changing policy, and how do we want to support changing policy
16:53:21 <kaeso_> and followup question: do those work in a container provided selinuxfs and policy-db are bind-mounted?
16:53:28 <walters> (already stated my larger feeling on the python thing)
16:53:31 <ajeddeloh> If we can run them in a toolbox then great, let's do that
16:54:09 <dustymabe> kaeso_: on Fedora Atomic Host I don't see any scriptlets that depend on them
16:54:15 <dustymabe> https://paste.fedoraproject.org/paste/7FgaLsA1QbfHm8fWlwYQTQ
16:54:16 <jlebon> i think they're mostly user utilities than APIs for other apps
16:54:28 <jlebon> scriptlets normally use semodule for installing selinux packages
16:54:39 <dustymabe> +1
16:55:09 <dustymabe> anyone apposed to excluding that package and see where we land?
16:55:17 <ajeddeloh> sgtm
16:55:22 <mnguyen_> +1
16:55:26 <jlebon> agreed
16:55:30 <kaeso_> dustymabe: ack, thanks. Can you persist that info to the ticket?
16:55:36 <dustymabe> kaeso_: sure
16:55:47 <lorbus[m]> +1
16:57:05 <bgilbert> +1
16:57:11 <dustymabe> #action dustymabe to update ticket #122 with results where we are going to try to exclude setools-console package and see where we land
16:57:13 <ksinny> +1
16:57:29 <dustymabe> #topic Keep/Remove Python dependent package: nfs-utils
16:57:31 <kaeso_> +1 me too. Perhaps with a followup RFE/doc to make sure they work when containerized
16:57:40 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/121
16:59:31 <dustymabe> sorry got pulled away
16:59:33 <ajeddeloh> On CL we ship the server too, not sure if anyone uses it
16:59:40 <dustymabe> mostly drawing attention to the final comment
17:00:01 <ajeddeloh> I'd like to have both server and client but the client is arguably the most important bit
17:00:25 <bgilbert> I hate to ask, but... can the server run containerized?
17:00:44 <bgilbert> I realize it's mostly a wrapper around the kernel nfsd
17:00:49 <dustymabe> bgilbert: AFAIK yes. I think someone chimed in and said that's what openshift does
17:01:19 <dustymabe> maybe it was in the last meeting someone said that
17:01:20 <kaeso_> bgilbert: https://github.com/kubernetes/examples/blob/master/staging/volumes/nfs/nfs-server-rc.yaml
17:01:40 <ajeddeloh> in that case I'd say run it in a container
17:01:48 <kaeso_> dustymabe: I think that was me in the other channel I think
17:01:55 <dustymabe> cool
17:02:12 <ajeddeloh> 99% of people probably wont use it, so that's less bits they need to worry about
17:02:22 <kaeso_> I also did a quick check on k8s and I *think* it will be fine with the client only
17:02:48 <bgilbert> any reason not to just ship the client and reserve the ability to add the server later?
17:02:50 <bgilbert> if need be
17:02:59 <ajeddeloh> bgilbert++
17:03:00 <kaeso_> I also run a quick poll with Berlin folks and didn't spot any usage of the on-host server
17:03:11 <yzhang> curious, for these containerized workflows are we planning on having separate containers in the e.g. the fedora registry to handle these use cases
17:03:24 <dustymabe> bgilbert: well. the reason we are having this discussion is related to python
17:03:34 <dustymabe> and if the server package has python - then we are back to square 1
17:04:02 <bgilbert> well, then we end up with nfs-utils-client and nfs-utils-server-coreos, right?  :-)
17:04:14 <dustymabe> perhaps :)
17:04:32 <dustymabe> i can add this information to the ticket
17:04:39 <dustymabe> s/ticket/BZ
17:04:43 <dustymabe> and see where the discussion goes
17:04:57 <kaeso_> (at that point we rename to fedora-cantor)
17:05:21 <dustymabe> #proposed we think shipping only the nfs client will suffice considering users can run nfs server in a container
17:05:35 <dustymabe> yzhang: I don't have an answer to that but would be nice if one existed
17:05:46 <dustymabe> wouldn't be hard to create one
17:05:57 <dustymabe> ack/nack on proposed text
17:06:08 <miabbott> ack
17:06:13 <ksinny> ack
17:06:25 <lorbus[m]> ack
17:06:30 <ajeddeloh> ack
17:07:00 <bgilbert> ack
17:07:03 <jbrooks> ack
17:07:16 <dustymabe> #agreed we think shipping only the nfs client will suffice considering users can run nfs server in a container
17:07:39 <dustymabe> #topic Keep/Remove Python dependent package: bind-utils
17:07:45 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/120
17:08:40 <dustymabe> bind-utils split a package out for us -  dnssec (with python stuff)
17:09:04 <dustymabe> does anyone see anything in that list of files in the bind-dnssec-utils package that we need?
17:09:06 <ajeddeloh> I think (hope) bind-utils and friends should containerize easily. Having bind-utils on host is probably good and dnssec can be run in a container if needed?
17:09:48 <dustymabe> ajeddeloh: yeah I'm not sure about the second part. but definitely need bind-utils on the host IMHO to debug dns issues
17:10:00 <dustymabe> because if you have dns issues it will be hard to pull down your "debug" container
17:10:02 <dustymabe> :)
17:10:51 <ajeddeloh> hmm I guess that's an issue if you can't not use dnssec? /me doesn't know a ton about dns
17:11:17 <dustymabe> yeah - i don't have good insight there either
17:11:42 <kaeso_> those are mostly dnsses management utils, not debugging ones
17:12:45 <dustymabe> #proposed we will try to ship just bind-utils without bind-dnssec-utils (python deps) and see if we hit any roadblocks
17:13:01 <dustymabe> anybody know of any good reason not to try ^^
17:13:23 <lorbus[m]> +1
17:13:32 <miabbott> a quick look at some of the man pages for those dnssec* utils seems to agree with what kaeso_ said
17:13:40 <lorbus[m]> DNSSEC is only used by what, 1% of sites?
17:14:20 * ksinny don't know much about these tools
17:14:36 <dustymabe> ack/nack
17:14:59 <bgilbert> ack
17:15:21 <ajeddeloh> ck
17:15:27 <ajeddeloh> ack*
17:15:27 <miabbott> ack
17:15:39 <mnguyen_> ack
17:15:53 <dustymabe> #agreed we will try to ship just bind-utils without bind-dnssec-utils (python deps) and see if we hit any roadblocks
17:16:04 <kaeso_> the only one that raises an eyebrow to me is `genrandom`
17:16:36 <dustymabe> #topic open floor
17:16:47 <dustymabe> kaeso_: yeah \o/ - not sure
17:17:06 <dustymabe> Anyone with anything for open floor?
17:17:10 <dustymabe> multi-arch friends?
17:17:31 <kaeso_> but just because it's seem so broad in scope that it could get random consumers/dependers
17:17:34 <dgilmore> dustymabe: just trying to get things working while the floor moves under us
17:17:53 <dustymabe> dgilmore: welcome to the merry-go-round
17:18:24 <dgilmore> dustymabe: once we get ppc64le and aarch64 working we will tackle s390x
17:18:55 <dustymabe> dgilmore: any small fixes you find I'd suggest posting a PR for it. that way we can get it "in" before the ground moves again
17:19:07 <bgilbert> +1
17:19:08 <dustymabe> i.e. don't collect a bunch of changes, just submit them as you find them
17:19:08 <dgilmore> dustymabe: trying to do that as we go
17:19:18 <dustymabe> +1
17:19:22 <dustymabe> thanks dgilmore!
17:19:39 <dgilmore> dustymabe: biggest issue right now is some wonkyiness with qemu and dealing with different locations for grub
17:19:50 <dustymabe> good to know
17:20:12 <dgilmore> grub is really a efi vs non efi issue right now
17:20:23 <lorbus[m]> random note regarding boot counting w/ grub: working on greenboot, splitting out essential red/green scripts into dedicated services, I think I came across a way to activate boot fallback counting in a very non-intrusive way (it's actually rather obvious): https://github.com/LorbusChris/greenboot/blob/0.7/usr/lib/systemd/system/greenboot-grub2-prep-upgrade.service
17:20:42 <dustymabe> dgilmore: related to that: https://github.com/coreos/coreos-assembler/issues/334
17:22:04 <ajeddeloh> Where we want to go with grub is having all grubs (even when installed on the same system) use the same config for 99% of what it does
17:22:19 <lorbus[m]> another random regarding greenboot: I hope to release v0.6 today, 0.7 branch exists, and I hope to get that in soon, once our selinux labeling issues are resolved
17:22:29 <dustymabe> lorbus[m]: you might have to explain to me in #fedora-coreos after the meeting what's new there :)
17:22:33 <dustymabe> been a while since I looked
17:22:45 <ajeddeloh> there's little bits that change between like bios and uefi (and presumably other firmware setups) but those should be abstracted so the one master grub config can handle it
17:22:53 <ajeddeloh> we're not there yet at all though
17:23:16 <ajeddeloh> i.e. booting on bios would load a bios config that does bios specific things then load the common config
17:23:44 <lorbus[m]> ajeddeloh: Essentially for boot counting we'd just need this snippet, which shouldnt interfere with anything else: https://github.com/rhboot/grub2/blob/fedora-30/util/grub.d/01_fallback_counting.in
17:23:48 <dustymabe> ajeddeloh: +1 I think rfairley might start looking at some of that work in rpm-ostree/ostree as soon as he gets you unblocked on the other issue
17:24:57 <ajeddeloh> lorbus[m]: I thought we were going to rework that long term to store the entirety of state in grub envvars
17:25:23 <dustymabe> we're getting a bit into details - move to #fedora-coreos ?
17:25:29 <dustymabe> anyone have anything else for open floor?
17:25:44 * dustymabe notes that we started creating images for "bare metal" recently
17:25:46 <lorbus[m]> ajeddeloh: that store's state there..doesn't that just mean adding more state later?
17:26:15 <dustymabe> #link https://github.com/coreos/fedora-coreos-pipeline/pull/43
17:26:22 <jlebon> dustymabe: have you tried out the ones spit out by the pipeline yet?
17:26:46 <dustymabe> jlebon: I have not downloaded one from the pipeline but I did build one locally and verify it worked
17:27:01 <dustymabe> it was the BIOS one, so haven't verified UEFI yet
17:27:05 <jlebon> nice, will have to give it a try
17:27:10 <lorbus[m]> but sure, once we have clearly defined what state we need and store, this can be aligned with the rest of env vars
17:27:18 <dustymabe> I installed it using the ISO installer work that I've been hacking on
17:27:26 <dustymabe> should have new PRs up for that work today and also an rpm
17:27:29 <ajeddeloh> lorbus[m]: lets sync up after this
17:27:51 <jlebon> dustymabe: a bit backwards, though would it work to qemu-img convert it back into a qcow2 and boot it as a VM?
17:28:10 <dustymabe> jlebon: you'd have to gf-oemid it too
17:28:23 <dustymabe> it doesn't have an oem-id IIRC
17:28:27 <jlebon> right, gotcha
17:28:44 <kaeso_> if there are ppc multi-arch folks around, I think this should get some spotlight https://github.com/coreos/ignition/issues/666
17:28:49 <dustymabe> note that you can use the raw image directly with qemu too (so no need to qemu-img convert) :)
17:29:04 <jlebon> +1
17:29:27 <bgilbert> kaeso_: +1
17:29:28 <dustymabe> kaeso_: yes. bgilbert did we ever dig in more on that libvirt discussion ?
17:29:45 <dustymabe> i know we were possibly going to open an issue for the proposed solution using PCI devices
17:29:46 <bgilbert> dustymabe: no, I was going to play with configuring QEMU PCI devices from the command line
17:29:49 <bgilbert> haven't gotten to it
17:29:51 <dustymabe> +1
17:30:14 * dustymabe will close out meeting in 50 seconds
17:30:47 <dustymabe> ajeddeloh: want to join #fedora-coreos to continue grub discussion?
17:30:49 <kaeso_> bgilbert: a PCI "ignition-store" cross-arch? or something different?
17:31:05 <bgilbert> kaeso_: basically that.  sounds like there are a couple potential ways to do it
17:31:14 <bgilbert> I'm not clear yet whether new code would be needed in QEMU, or how much
17:31:44 <kaeso_> bgilbert: ack, nice
17:31:49 <ajeddeloh> dustymabe: sure
17:31:52 <dustymabe> #endmeeting