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