16:30:12 <slowrie> #startmeeting fedora_coreos_meeting
16:30:12 <zodbot> Meeting started Wed Jul 25 16:30:12 2018 UTC.
16:30:12 <zodbot> This meeting is logged and archived in a public location.
16:30:12 <zodbot> The chair is slowrie. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:30:12 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:30:12 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:30:14 <zodbot> ajeddeloh: ajeddeloh 'Andrew Jeddeloh' <andrew.jeddeloh@redhat.com>
16:30:18 <csssuf> .hello2
16:30:19 <zodbot> csssuf: csssuf 'James Forcier' <jforcier@redhat.com>
16:30:19 <bgilbert> .hello2
16:30:20 <dustymabe> .hello2
16:30:20 <slowrie> #chair lorbus
16:30:21 <zodbot> Current chairs: lorbus slowrie
16:30:22 <zodbot> bgilbert: bgilbert 'Benjamin Gilbert' <bgilbert@backtick.net>
16:30:24 <mnguyen_> .hello2
16:30:24 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:30:25 <slowrie> #chair ajeddeloh
16:30:25 <zodbot> Current chairs: ajeddeloh lorbus slowrie
16:30:27 <zodbot> mnguyen_: Sorry, but you don't exist
16:30:29 <slowrie> #chair csssuf
16:30:29 <zodbot> Current chairs: ajeddeloh csssuf lorbus slowrie
16:30:37 <sayan> .hello sayanchowdhury
16:30:38 <zodbot> sayan: sayanchowdhury 'Sayan Chowdhury' <sayan.chowdhury2012@gmail.com>
16:30:39 <slowrie> .hello2
16:30:43 <mnguyen_> .hello mnguyen
16:30:44 <zodbot> slowrie: slowrie 'Stephen Lowrie' <slowrie@redhat.com>
16:30:45 <miabbott> .hello miabbott
16:30:46 <slowrie> #chair sayan
16:30:46 <zodbot> Current chairs: ajeddeloh csssuf lorbus sayan slowrie
16:30:48 <zodbot> mnguyen_: mnguyen 'Michael Nguyen' <mnguyen@redhat.com>
16:30:51 <zodbot> miabbott: miabbott 'Micah Abbott' <miabbott@redhat.com>
16:30:51 <slowrie> .chair mnguyen
16:30:54 <zodbot> mnguyen is seated in a chair with a nice view of a placid lake, unsuspecting that another chair is about to be slammed into them.
16:30:58 <slowrie> #char miabbott
16:31:01 <rfairley> .hello rfairley-redhat
16:31:02 <zodbot> rfairley: Sorry, but you don't exist
16:31:03 <slowrie> #chair miabbott
16:31:03 <zodbot> Current chairs: ajeddeloh csssuf lorbus miabbott sayan slowrie
16:31:07 <slowrie> #chair mnguyen
16:31:07 <zodbot> Current chairs: ajeddeloh csssuf lorbus miabbott mnguyen sayan slowrie
16:31:08 <rfairley> .hello rfairley
16:31:12 <zodbot> rfairley: Sorry, but you don't exist
16:31:13 <sanja> .hello2
16:31:15 <zodbot> sanja: sanja 'Sanja Bonic' <sanja@redhat.com>
16:31:17 <slowrie> #chair rfairley
16:31:17 <zodbot> Current chairs: ajeddeloh csssuf lorbus miabbott mnguyen rfairley sayan slowrie
16:31:19 <slowrie> #chair sanja
16:31:19 <zodbot> Current chairs: ajeddeloh csssuf lorbus miabbott mnguyen rfairley sanja sayan slowrie
16:31:28 <geoff-> Hi, my name is Geoff Levand <geoff@infradead.org>
16:31:30 <sanja> I made it (at least for a bit, might have to go sooner)
16:31:33 <slowrie> #chair geoff-
16:31:33 <zodbot> Current chairs: ajeddeloh csssuf geoff- lorbus miabbott mnguyen rfairley sanja sayan slowrie
16:31:34 <miabbott> nice .chair command zodbot
16:31:52 <slowrie> #chair bgilbert
16:31:52 <zodbot> Current chairs: ajeddeloh bgilbert csssuf geoff- lorbus miabbott mnguyen rfairley sanja sayan slowrie
16:32:20 <ksinny> .hello sinnykumari
16:32:21 <zodbot> ksinny: sinnykumari 'Sinny Kumari' <ksinny@gmail.com>
16:32:26 <slowrie> #chair sinnykumari
16:32:26 <zodbot> Current chairs: ajeddeloh bgilbert csssuf geoff- lorbus miabbott mnguyen rfairley sanja sayan sinnykumari slowrie
16:32:51 <rfairley> .hello rfairleyredhat
16:32:52 <zodbot> rfairley: rfairleyredhat 'Robert Fairley' <rfairley@redhat.com>
16:33:52 <slowrie> Ok, let's get started
16:33:56 <slowrie> #topic Action items from last meeting
16:34:05 <jberkus> .hello jberkus
16:34:06 <zodbot> jberkus: jberkus 'Josh Berkus' <josh@agliodbs.com>
16:34:11 <slowrie> bgilbert: dustymabe: sanja: were working on the Fedora CoreOS user stories
16:34:14 <jdoss> .hello jdoss
16:34:14 <slowrie> #chair jberkus
16:34:14 <zodbot> Current chairs: ajeddeloh bgilbert csssuf geoff- jberkus lorbus miabbott mnguyen rfairley sanja sayan sinnykumari slowrie
16:34:15 <zodbot> jdoss: jdoss 'Joe Doss' <joe@solidadmin.com>
16:34:17 <slowrie> #chair jdoss
16:34:17 <zodbot> Current chairs: ajeddeloh bgilbert csssuf geoff- jberkus jdoss lorbus miabbott mnguyen rfairley sanja sayan sinnykumari slowrie
16:34:37 <slowrie> Were there any updates on that front?
16:35:17 <dustymabe> slowrie: yep bgilbert and I and a few others of us from RH chatted last week
16:35:18 <sanja> Yes and no - we had the session where we identified goals.
16:35:32 <sanja> dustymabe I'll let you talk on that one
16:35:33 <dustymabe> I added an update to the card which we can discuss in am inute
16:35:38 <slowrie> #chair dustymabe
16:35:38 <zodbot> Current chairs: ajeddeloh bgilbert csssuf dustymabe geoff- jberkus jdoss lorbus miabbott mnguyen rfairley sanja sayan sinnykumari slowrie
16:35:47 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/7#issuecomment-407532435
16:36:10 <dustymabe> that ticket is also a meeting item so maybe we can discuss more then
16:36:22 <slowrie> Yeah we'll cover that in the topics for today
16:36:35 <slowrie> So let's move on to the other action item, cverna: dustymabe: were working on a strategy for the containers working group
16:36:51 <jlebon> .hello jlebon
16:36:52 <zodbot> jlebon: jlebon 'None' <jonathan@jlebon.com>
16:36:55 <cverna> hello o/
16:36:57 <slowrie> #chair jlebon
16:36:57 <zodbot> Current chairs: ajeddeloh bgilbert csssuf dustymabe geoff- jberkus jdoss jlebon lorbus miabbott mnguyen rfairley sanja sayan sinnykumari slowrie
16:37:00 <slowrie> #chair cverna
16:37:00 <zodbot> Current chairs: ajeddeloh bgilbert csssuf cverna dustymabe geoff- jberkus jdoss jlebon lorbus miabbott mnguyen rfairley sanja sayan sinnykumari slowrie
16:37:07 <dustymabe> cverna: o/
16:37:07 <mshipman> .hello mshipman
16:37:08 <zodbot> mshipman: mshipman 'Matt Shipman' <matthew-shipman@pluralsight.com>
16:37:12 <slowrie> #chair mshipman
16:37:12 <zodbot> Current chairs: ajeddeloh bgilbert csssuf cverna dustymabe geoff- jberkus jdoss jlebon lorbus miabbott mnguyen mshipman rfairley sanja sayan sinnykumari slowrie
16:37:13 <jlebon> howdy all!
16:37:31 <cverna> I will be sending later today an email about a futur container SIG so I think we can close this item
16:37:53 <dustymabe> cverna: +1
16:37:57 <dustymabe> can you add an update to the card ?
16:38:07 <dustymabe> s/card/issue ?
16:38:57 <lorbus> oh is creating a Container SIG a done deal already?
16:39:45 <dustymabe> lorbus: i think his email is to propose it
16:39:57 <sanja> yeah, and then people can chime in
16:40:06 <cverna> lorbus: yes pretty much once the email is out and people are interested in that should be it
16:40:07 <lorbus> dustymabe, cverna, sanja: +1
16:40:19 <cverna> I ll update the ticket
16:40:21 <slowrie> ok, so sounds like we should have an email out later today, do we want to have a follow up action for next meeting or does that live outside of our group?
16:40:29 <sanja> outside I think
16:40:47 <slowrie> alright, topics for today will come from here:
16:40:49 <slowrie> #link https://github.com/coreos/fedora-coreos-tracker/labels/meeting
16:41:11 <slowrie> #topic flesh out use cases for Fedora CoreOS
16:41:20 <slowrie> #link https://github.com/coreos/fedora-coreos-tracker/issues/7
16:41:29 * dustymabe waves
16:41:47 <slowrie> Looks like we have some use cases and a PRD is in the works, dustymabe do you want to talk about it a bit
16:42:41 <dustymabe> as mentioned above we've tried to come up with an initial draft of use cases for FCOS. This is a starting point to engage in conversation with the community
16:44:37 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/7#issuecomment-407532435
16:46:09 <jlebon> hmm, should the "non Kubernetes" be in the "indifferent" rather than "secondary" section?
16:46:23 <bgilbert> yeah, I was just noticing that
16:46:28 <dustymabe> perhaps ?
16:46:29 <geoff-> I think the secondary use case 'general cluster node' is an important one.
16:46:34 <jlebon> i.e. we're not actively working towards that, just that we're not impeding it
16:47:02 <bgilbert> CL's locksmith is primarily for the clustered non-k8s case
16:47:21 <bgilbert> and for users migrating from that CL use case we'll need something like locksmith in FCOS
16:48:00 * dustymabe a bit confused. anyone want to make a proposal ?
16:48:01 <bgilbert> so the clustered non-k8s case should be ranked sufficiently that we spend time on it :-)
16:48:14 <slowrie> bgilbert: would locksmith not also fall into the single node use case
16:48:55 <jlebon> bgilbert: ahh, i thought locksmith/$successor was also going to cover the k8s case in FCOS
16:48:56 <bgilbert> it could be used there, but e.g. rpm-ostree self-managing reboots would also work fine
16:49:18 <bgilbert> $successor hasn't been precisely defined yet, so maybe?
16:49:36 <bgilbert> but so far that's been CLUO, with the cluster completely managing the node
16:49:40 <bgilbert> (Container Linux Update Operator)
16:50:58 <jlebon> i definitely agree tools we develop should be generic enough to be adaptable to other platforms
16:51:00 <slowrie> For context there is also an issue talking about etcd & locksmith here:
16:51:02 <slowrie> #link https://github.com/coreos/fedora-coreos-tracker/issues/3
16:51:06 <bgilbert> in any event, we should probably define the consequences of "primary" and "secondary" before deciding what goes into the lists
16:51:15 <geoff-> I don't think it would be good if a user's cluster breaks on upgrade because his use is 'indifferent'
16:51:24 <dustymabe> bgilbert: that's probably a good idea
16:52:24 <dustymabe> any suggestions for definition of primary vs seconday vs indifferent vs anti ?
16:53:08 * dustymabe waves, hi ed
16:53:09 <slowrie> I personally think that primary should probably carry some form of context that we're testing something related to it
16:53:15 <ed-packet> hi hi dustymab
16:53:17 <ajeddeloh> geoff-: I think the difference is in testing and bug hunting. We can't test every container orchestrator. We can't hunt down every bug. I think indifferent means "we try to support this, but we don't test it as well and we can't take the same amount of time to hunt down bugs"
16:53:24 <ed-packet> *dustymabe
16:53:50 <ed-packet> why can't we test every container orchestrator
16:53:58 <slowrie> #chair ed-packet
16:53:58 <zodbot> Current chairs: ajeddeloh bgilbert csssuf cverna dustymabe ed-packet geoff- jberkus jdoss jlebon lorbus miabbott mnguyen mshipman rfairley sanja sayan sinnykumari slowrie
16:54:01 <ed-packet> there are a finite number of them
16:54:26 <dustymabe> started an etherpad
16:54:29 <slowrie> ed-packet: Time constraints maintaining the testing and test run times is usually a huge impediment
16:54:39 <ed-packet> slowrie: so get faster machines
16:54:48 <ajeddeloh> also, the number of them will likely grow
16:55:00 <bgilbert> ed-packet: there are many configurations.  we could limit ourselves to smoke testing, but that doesn't prove much
16:55:05 <ed-packet> ajeddeloh: so, get more machines. tests can run in parallel
16:55:11 <ajeddeloh> ed-packet: a lot of testing time is impacted not by machine speed but by cloud speed spinning up/down machines
16:55:24 <bgilbert> ed-packet: we're not experts in e.g. mesos or docker swarm
16:55:46 <slowrie> As well, in some cases the configuration time has to be done in sequence and is non-trivial
16:55:47 <geoff-> who knows how to do an HPC cluster?
16:55:52 <bgilbert> if someone is, and wants to help, I don't see why they couldn't
16:55:54 <ed-packet> ajeddeloh: understood on cloud speed spin up time, that is a tough problem (but something I am familiar with)
16:55:58 <dustymabe> https://public.etherpad-mozilla.org/p/primaryVSsecondary
16:56:13 <slowrie> #link https://public.etherpad-mozilla.org/p/primaryVSsecondary
16:56:14 <ed-packet> bgilbert: I know some mesos people from when they ported mesos to arm
16:58:59 <dustymabe> ok so we've got some stuff in the etherpad
16:59:04 <dustymabe> let's discuss
16:59:11 <dustymabe> primary:
16:59:14 <dustymabe> factored into design decisions
16:59:16 <dustymabe> actively tested
16:59:18 <dustymabe> bugs are actively fixed
16:59:20 <dustymabe> any issues with above ?
16:59:42 <slowrie> "tooling support is provided" was added
16:59:48 <dustymabe> maybe don't focus on perfect wording but just that there isn't any incorrect statements
17:00:32 <dustymabe> slowrie: that might be a little overarching, but we can discuss details on that later probably
17:00:43 <dustymabe> any acks/nacks ?
17:00:54 <slowrie> silence == agreement
17:01:20 <dustymabe> k
17:01:33 <dustymabe> i'll run through the last 2 and come back to secondary
17:01:44 <dustymabe> indifferent:
17:01:46 <dustymabe> you could possibly use Fedora CoreOS for this but this use case is not considered when doing development and could break over time
17:01:48 <dustymabe> no decision to consciously break the use case
17:02:36 <dustymabe> I added "unless conflicts with primary goals"
17:03:08 <dustymabe> i.e. we could possibly end up changing something that hurts IoT if it helps out other goals
17:03:17 <dustymabe> is that accurate or not ?
17:03:23 <jlebon> 👍
17:03:29 <bgilbert> +1
17:03:38 <slowrie> +1
17:03:40 <mshipman> +1
17:03:54 <jberkus> +1
17:03:55 * ajeddeloh isn't using a font that can see jlebon's message.
17:03:59 <ajeddeloh> +1
17:03:59 <dustymabe> jlebon: confused ?
17:04:05 <jlebon> haha
17:04:09 <dustymabe> ajeddeloh: just looks like a ? to me
17:04:09 <jlebon> :thumbsup:
17:04:19 <dustymabe> haha
17:04:20 <miabbott> get your emoji game on point folks
17:04:21 <dustymabe> ok
17:04:29 <dustymabe> emoji smoji
17:04:29 <jlebon> this is 2018
17:04:33 <jlebon> the year of the emoji
17:04:36 <bgilbert> and we're on IRC
17:04:37 <dustymabe> ok next one
17:04:39 <ed-packet> unicode ftw
17:04:44 <miabbott> ed-packet gets it
17:04:44 <dustymabe> anti:
17:04:47 <dustymabe> please don't use Fedora CoreOS for this
17:05:09 <slowrie> +1
17:05:09 <dustymabe> i can add some more wording, but basically "you're use case will probably break and we don't care because we told you not to"
17:05:11 <jdoss> unicode can't use FCOS? Got it.
17:05:42 <mnguyen_> +1
17:05:43 <geoff-> the word 'unsupported' come to mind...
17:05:51 <bgilbert> +1
17:06:01 <bgilbert> more than unsupported; actively discouraged
17:06:03 <ed-packet> "please do not use this code to run a nuclear weapon"
17:06:07 <dustymabe> haha
17:06:10 <dustymabe> ok final one
17:06:19 <dustymabe> secondary:
17:06:22 <dustymabe> factored into design decisions
17:06:24 <dustymabe> some tooling support is provided
17:06:26 <dustymabe> tested, but perhaps not as thoroughly
17:06:28 <dustymabe> bugs are actively fixed, but may not be high priority or may just be handed upstream
17:06:41 <ajeddeloh> basically primary but worse
17:06:43 <slowrie> I'm not sure that we want to commit to having testing for all non-k8s coordinators
17:06:44 <bgilbert> the exact boundaries here are pretty fuzzy
17:06:45 * sanja has to go for now. Have a good <insert daytime depending on where you are>.
17:06:47 <bgilbert> but I don't think that's avoidable
17:06:50 <dustymabe> i wonder if we should say "may be tested" instead of "tested, but perhaps not as thoroughly"
17:06:58 <slowrie> I don't think we'd actively reject it if someone were to add it
17:06:59 <lorbus> bye sanja!
17:07:08 <ajeddeloh> dustymabe +1
17:07:09 <dustymabe> right I agree with that
17:07:13 <ed-packet> "passes at least one test"
17:07:13 <geoff-> I think if there is a significant user community for some use case it should be a secondary use case, an a best attempt is made to support it.
17:07:30 <bgilbert> running with the earlier example, we might test locksmith but not swarm
17:07:57 <slowrie> bgilbert: I'd agree to that, but the current wording implies that we'd have something testing swarm directly
17:08:14 <bgilbert> "some testing"?
17:08:17 <ed-packet> "at least one test exists, and there is at least one current run of that test in the past week, which might or might not have passed"
17:08:31 <dustymabe> #propose replace "tested, but perhaps not as thoroughly" with "may be tested"
17:08:42 <ed-packet> SHOULD be tested
17:08:58 <slowrie> ed-packet: in the case of the non-k8s cluster coordinators what would the process have to be to be added
17:09:14 <ed-packet> dunno, that's an excellent question
17:09:37 <dustymabe> yeah I think these goals can change over time
17:09:56 <slowrie> I'd prefer not to add tests for the sake of adding them
17:09:59 <geoff-> maybe have something about a maintainer for a secondary use case
17:10:11 <dustymabe> but for right now I don't really want to commit to testing other orchestration platforms
17:10:14 <slowrie> If they're just going to run a smoke test there's a very minimal effort
17:10:19 <dustymabe> i personally don't have any experience with them
17:10:23 <slowrie> dustymabe: agreed
17:10:48 <ed-packet> agreed with geoff- a designated point of contact (or two) would be good to collect. if no poc, then no secondary support
17:10:48 <bgilbert> there's also a distinction between supporting "other orchestrators" as an abstraction, and supporting specific orchestrators
17:11:23 <ed-packet> my immediate interest to be clear is "other architectures" more so than "other orchestrators", e.g. arm64
17:11:35 <bgilbert> right, same thing there
17:11:45 <dustymabe> ed-packet: +1
17:12:11 <dustymabe> i think it's a bit of apples/oranges comparison, but I see the logical leap
17:12:30 <ed-packet> just budgeting how many thunderx systems I need to have on tap (on demand best) to test this at packet-net for worksonarm
17:12:32 <bgilbert> dustymabe: I don't think it's so different?
17:12:58 <bgilbert> we might support locksmith but not test any other orchestrators.  we might have architecture-independence in our tooling but not build/test multiple arches.
17:12:59 <dustymabe> we don't have listed out primary/secondary arch use cases specifically in that issue but I did add this to the PRD
17:13:25 <dustymabe> https://fedoraproject.org/wiki/CoreOS/PRD#Architectures
17:13:31 <slowrie> okay, so do we want to make an action item for dustymabe to update the issue/PRD with the distinctions for the different categories and we can move on to the next topic (arm64/aarch64)?
17:13:31 <ed-packet> ☈x for you unicode fans hi hi
17:13:56 <ed-packet> ++
17:14:10 <dustymabe> slowrie: one second
17:14:12 <slowrie> ok
17:14:26 <dustymabe> let me copy/paste what we had for use case definitions real quick for posterity
17:15:07 <dustymabe> primary:
17:15:10 <dustymabe> factored into design decisions
17:15:12 <dustymabe> tooling support is provided
17:15:14 <dustymabe> actively tested
17:15:16 <dustymabe> bugs are actively fixed
17:15:18 <dustymabe> secondary:
17:15:20 <dustymabe> factored into design decisions
17:15:22 <dustymabe> some tooling support is provided
17:15:24 <dustymabe> may be tested (community points of contact may make stronger guarantees on this)
17:15:26 <dustymabe> bugs are actively fixed, but may not be high priority or may just be handed upstream
17:15:28 <dustymabe> indifferent:
17:15:30 <dustymabe> you could possibly use Fedora CoreOS for this but this use case is not considered when doing development and could break over time
17:15:32 <dustymabe> no decision to consciously break the use case, unless conflicts with primary goals
17:15:34 <dustymabe> anti:
17:15:36 <dustymabe> please don't use Fedora CoreOS for this
17:15:38 <dustymabe> I'll try to update the issue and PRD with the above (I'll paraphrase and clean up wording)
17:15:44 <slowrie> #action dustymabe update the issue/PRD with distinctions for the different categories
17:16:13 <slowrie> #topic arm64 / aarch64 support for Fedora CoreOS
17:16:22 <slowrie> #link https://github.com/coreos/fedora-coreos-tracker/issues/13
17:16:42 * dustymabe waves at ed-packet
17:18:03 <bgilbert> (at some point we should circle back to the use cases in light of those definitions)
17:18:18 <ed-packet> waving back
17:18:32 <ed-packet> waves at geoff-
17:18:57 <slowrie> bgilbert: unless we close the issue it'll come back up next meeting as a continuation aiui
17:18:59 <geoff-> for the idea of maintainers it would be good to have those listed somewhere
17:19:00 <ed-packet> so the question I have is how to support arm64
17:19:54 <dustymabe> ed-packet: I'd like to think that it won't be too hard to do since we've got a lot of infra set up for it already in Fedora
17:20:05 <ed-packet> my ideal is that coreos fedora works perfectly on thunderx at packet, and i tested frequently (at minimum daily ideally every checkin)
17:20:33 <dustymabe> the caveat there being, fedora has some limitations (primarily in speed) with infrastructure that we'd like to enhance and might make changes to the way we build
17:20:35 <ed-packet> the missig link dustymabe is fedora on packet, we have centos running but I have not been able to get fedora pushed into production.
17:20:48 <dustymabe> ed-packet: oh?
17:20:55 <dustymabe> is that a technical limitation or other?
17:21:02 <ed-packet> sorry for lag, typing blind on airplane
17:21:54 <ed-packet> we can boot ipxe and i got f27 running on tx. but it was a one off and not a reproducable build.
17:22:05 <slowrie> ed-packet: kola already supports packet.net, and can use custom images via ipxe magic, so it should be possible to test it if we are releasing the right images
17:22:16 <ed-packet> perfecto
17:22:33 <bgilbert> and specifically supports ARM64 on Packet
17:22:38 <ed-packet> kola++
17:23:04 <slowrie> #link https://github.com/coreos/mantle/blob/master/platforms.md#packet
17:23:13 <dustymabe> ed-packet: hopefully any technical limitations can be easily solved (especially considering the fact that the CL team has already been doing this with CL)
17:23:14 <slowrie> very brief overview of the way it works
17:23:23 <bgilbert> ed-packet: what was the problem with f27?
17:23:34 <bgilbert> i.e., what fixes went into your one-off
17:24:08 <ed-packet> bgilbert: tx nic issue iirc, fixed promptly with probinson help
17:24:23 <ed-packet> fixes went  upstream
17:24:34 <ed-packet> f29 should be a-ok
17:25:31 <bgilbert> I do think there's some value in multi-arch support on day 1.  prevents us from making bad decisions.
17:25:44 <slowrie> bgilbert: +1
17:25:45 <bgilbert> well, certain bad decisions
17:25:56 <ksinny> +1
17:26:05 <dustymabe> bgilbert: if "day 1" is fedora 30 release day, then I agree with you
17:26:05 <slowrie> okay, did we have any other concerns / questions we wanted to have on this topic?
17:26:11 <bgilbert> dustymabe: +1
17:26:16 <slowrie> dustymabe: +1
17:26:23 <ed-packet> f30 a good target
17:26:24 <dustymabe> if "day 1" is the first day we ever have a fedora coreos build, then maybe not :)
17:26:26 <geoff-> +1, although the PRD  currently says 'hope to add other architectures '
17:26:37 <slowrie> hopefully with some experimental builds in the interim
17:27:01 <geoff-> day one as a secondary arch?
17:27:16 <bgilbert> slowrie: all builds may be experimental builds in the interim :-)
17:27:36 <slowrie> bgilbert: of course, I was more meaning we'd have some builds that'd happen before f30 for it
17:27:45 <dustymabe> geoff-: I think it's more a hedge. If we are having trouble getting FCOS out the door at all then unfortunately we are going to have to concentrate on x86_64 first
17:28:10 <dustymabe> I don't like it, but it's a harsh reality
17:29:05 <ed-packet> if fcos/f29 is tested at packet on x86_64 we can have the tooling  in  place
17:29:31 <dustymabe> +1
17:29:36 <dustymabe> let's all try to make it happen
17:29:48 <ed-packet> +1
17:29:49 <slowrie> okay, for time reasons can we move on to the open floor then?
17:29:59 <dustymabe> +1
17:30:03 <slowrie> #topic Open Floor
17:30:41 <slowrie> Does anyone have anything for the open floor?
17:30:51 <jdoss> Kernel module support is on my mind but it can be punted until a future meeting.
17:31:02 <ed-packet> I am in SJC Wed Thu, happy to share a schedule if someone wants to talk f2f
17:31:14 <slowrie> jdoss: do you want to work with dustymabe or sanja to get a meeting issue added
17:31:37 <ajeddeloh> Any thoughts on the proposed partition layout?
17:31:51 <ajeddeloh> (partition 1 is ESP, 2 is bios-boot, 3 is rootfs)
17:31:59 <dustymabe> jdoss: did already open a ticket, but did not add meeting label
17:32:00 <jdoss> slowrie: yea I can do that for the next meeting. It can be punted for now.
17:32:04 <slowrie> partition layout @
17:32:04 <ajeddeloh> gpt, install both bios grub and efi grub
17:32:06 <slowrie> #link https://github.com/coreos/fedora-coreos-tracker/issues/18
17:32:15 <dustymabe> ajeddeloh: let's add meeting label to that one
17:32:31 <ajeddeloh> done
17:32:37 <slowrie> alright, so we'll have kernel modules & partition layout for the next one
17:32:47 <slowrie> We're a bit over time so unless anyone has anything going to end the meeting in 1 min
17:32:56 <ed-packet> tyvm!
17:33:02 <dustymabe> slowrie: and also circling back on the use case discussion
17:33:11 <slowrie> dustymabe: yup!
17:33:12 <jdoss> great job slowrie on running the meeting :D
17:33:18 <bgilbert> +1
17:33:22 <dustymabe> sorry bgilbert I forgot to revisit actual use cases after we had the primary vs secondary worked out
17:33:30 <bgilbert> dustymabe: no prob
17:33:41 <ed-packet> :+1: for you unicode peoples
17:33:47 <slowrie> #endmeeting