16:30:41 #startmeeting fedora_coreos_meeting 16:30:41 Meeting started Wed Jul 11 16:30:41 2018 UTC. 16:30:41 This meeting is logged and archived in a public location. 16:30:41 The chair is dustymabe. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:30:41 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:30:41 The meeting name has been set to 'fedora_coreos_meeting' 16:30:47 #topic roll call 16:31:03 .hello rubaoredhat 16:31:04 rubao: rubaoredhat 'Ruixin Bao' 16:31:06 .hello 16:31:07 slowrie: (hello ) -- Alias for "hellomynameis $1". 16:31:10 hello 16:31:19 .hello 16:31:19 geoff-: (hello ) -- Alias for "hellomynameis $1". 16:31:28 .hello slowrie 16:31:29 slowrie: slowrie 'Stephen Lowrie' 16:31:32 .hello mnguyen 16:31:36 mnguyen_: mnguyen 'Michael Nguyen' 16:31:41 .hello2 16:31:42 bgilbert: bgilbert 'Benjamin Gilbert' 16:31:43 .hello2 16:31:45 ajeddeloh: ajeddeloh 'Andrew Jeddeloh' 16:31:54 .hello sayanchowdhury 16:31:55 sayan: sayanchowdhury 'Sayan Chowdhury' 16:32:09 .hello geoff- 16:32:10 geoff-: Sorry, but you don't exist 16:32:16 #chair rubao slowrie cverna geoff- mnguyen_ ajeddeloh bgilbert sayan 16:32:16 Current chairs: ajeddeloh bgilbert cverna dustymabe geoff- mnguyen_ rubao sayan slowrie 16:32:24 geoff-: do you happen to have a fedora fas account ? 16:32:26 .hello kaeso 16:32:27 kaeso: Sorry, but you don't exist 16:32:29 .fas jasonbrooks 16:32:30 jbrooks: jasonbrooks 'Jason Brooks' 16:32:34 .hello lucab 16:32:36 kaeso: lucab 'Luca Bruno' 16:32:42 zodbot uses that information for .hello 16:32:42 dustymabe: no, no account 16:32:48 no worries :) 16:32:53 .hello2 16:32:54 lorbus: lorbus 'Christian Glombek' 16:33:01 just say "hi may name is ____ _____" 16:33:07 .hello2 16:33:08 dustymabe: dustymabe 'Dusty Mabe' 16:33:34 #chair kaeso jbrooks lorbus 16:33:34 Current chairs: ajeddeloh bgilbert cverna dustymabe geoff- jbrooks kaeso lorbus mnguyen_ rubao sayan slowrie 16:34:20 hi may name is 'Geoff Levand' 16:34:36 welcome geoff- !! 16:34:46 hi geoff-! 16:35:14 * dustymabe heard rumors ed-packet was going to join us too 16:35:42 .hello sinnykumari 16:35:43 ksinny: sinnykumari 'Sinny Kumari' 16:36:05 #chair ksinny 16:36:05 Current chairs: ajeddeloh bgilbert cverna dustymabe geoff- jbrooks kaeso ksinny lorbus mnguyen_ rubao sayan slowrie 16:36:16 ok, let's get started 16:36:27 #topic previous meeting action items 16:36:53 good news :) - since last time was our first meeting we didn't have any action items 16:37:08 However, there were a few things that happened since last time 16:37:36 #info there was a community vote on GitHub/Pagure for an issue/feature tracker for Fedora CoreOS 16:37:51 #info votes resulted in GitHub getting chosen 16:38:22 #info we created https://github.com/coreos/fedora-coreos-tracker to house our dev related discussions and issue tracking 16:38:59 If you want to add agenda items for us to discuss in future meetings please open an issue there and ask for the meeting tag to be applied to the issue 16:39:48 any questions ? 16:39:50 .hello jlebon 16:39:51 jlebon: jlebon 'None' 16:39:55 welcome jlebon 16:40:00 #chair jlebon 16:40:00 Current chairs: ajeddeloh bgilbert cverna dustymabe geoff- jbrooks jlebon kaeso ksinny lorbus mnguyen_ rubao sayan slowrie 16:40:06 o/ jlebon 16:40:19 howdy all! sorry I'm late! 16:40:19 * cverna saw a github bot that allow users to apply tags by leaving a comment in the issue 16:40:37 that could be useful 16:40:55 we should evolve over time 16:41:14 I think it was https://github.com/zulip/zulipbot 16:41:18 anything before I move to topics for today's meeting ? 16:42:01 ok, topics will come from here: https://github.com/coreos/fedora-coreos-tracker/labels/meeting 16:42:07 #link https://github.com/coreos/fedora-coreos-tracker/labels/meeting 16:42:16 #topic rules for membership and voting 16:42:23 #link https://github.com/coreos/fedora-coreos-tracker/issues/1 16:42:57 this is carried forward from the atomic working group. at some point I'd like to establish some sort of governance structure for the project 16:43:17 in practice we had to use strict voting very little in the atomic working group and we just used lazy concensus 16:43:31 but having something written down is always useful 16:43:49 I expect sanja to have input on this when she comes back from vacation 16:45:13 any thoughts on this before I move to next topic? 16:45:40 I think it looks good :) 16:46:00 sgtm too 16:46:22 I encourage everyone to weigh in, in the ticket 16:46:29 if they have any input 16:46:31 👍 16:46:51 mnguyen_: question? 16:47:09 no, just agreeing 16:47:14 #topic should notifications from github issue tracker go to the mailing list? 16:47:21 #link https://github.com/coreos/fedora-coreos-tracker/issues/5 16:47:55 I added my thoughts in the ticket. /me allows everyone some time to read. 16:48:39 dustymabe, I agree, I prefer a less noisy list 16:48:44 +1 16:48:45 I agree with dustymabe 16:48:49 I am in favour for leaving the mailing list alone 16:48:49 +1 16:48:49 +1 16:48:53 +1 for using subscribe if someone wants to get notifed 16:49:09 dustymabe: additional sub-item for that, travis and other CI may want to send notifications too for breakage on periodic jobs 16:49:33 +1 16:49:43 kaeso: we should probably have individuals subscribe to those alerts too? 16:49:56 or are you suggesting we create a separate list for alerts like that ? 16:49:57 kaeso: Individual subscriptions or a separate ML would work better IMO 16:50:35 I *think* you can't subscribe to a third-party repo on travis 16:50:36 If we want a notifications list, seperate list++ 16:51:14 kaeso: got it. we can deal with this issue separately from #5 probably 16:51:39 I'd say either go ahead and create and issue where we can discuss it, OR wait til we actually have notifications and then create the issue :) 16:51:55 +1 for me, we can always bring up GH issues on the list too if they warrant higher visibility 16:52:20 dustymabe: perhaps yes, it was mostly another point for "separate notification ML" 16:52:34 #agreed we will allow individuals to subscribe to the GH tracker and not send notifications to the mailing list 16:52:41 ^^ anyone opposed to that statement ? 16:53:44 silence == agreement 16:54:02 #topic flesh out use cases for Fedora CoreOS 16:54:12 #link https://github.com/coreos/fedora-coreos-tracker/issues/7 16:55:08 Has there been anything published that describes what Fedora CoreOS is? 16:55:09 basically it would be good as we move forward to define what we are and what we are not so that we can more easily make decisions about the future of the project 16:55:25 geoff-: primarily the mission statement on https://coreos.fedoraproject.org/ 16:55:36 which I think is a good start, but +1 to more detailed use cases 16:55:45 bgilbert++ 16:56:31 I propose that a few of us try to write up a document and propose it as a starting point for the community 16:56:53 geoff-: the above plus discussions at https://discussion.fedoraproject.org/c/coreos 16:57:41 imo it should fill the role CL does today: it's for running containers (with or without orchestration), and not much else 16:58:05 should other projects based on what previously was Atomic be mentioned there, too? (silverblue, IoT) 16:58:25 i.e. not your laptop/desktop 16:58:33 lorbus: maybe mentioned and referenced, but not included I don't think 16:58:57 i.e. IoT should have it's own set of user stories 16:59:12 otherwise it wouldn't be a separate effort IMO 16:59:30 there is probably a fair amount of overlap, but that's ok 16:59:41 I agree. In this sense CoreOS, Silverblue and IoT will somewhat be siblings in the sense that they'll all be based off of OSTree 16:59:51 ok how about this: 17:00:18 #action dustymabe, bgilbert, sanja work on first draft of user stories for Fedora CoreOS 17:00:31 based on that mission statement it seems it is for server distro, not for a 'desktop' distro 17:00:33 this will probably take a few weeks (as some of us have a work trip next week) 17:01:03 geoff-: indeed, this is targeted towards servers, not user desktops 17:01:26 Silverblue would be the one for desktops 17:01:36 anyone opposed to that action item? 17:02:21 dustymabe: I'm not a huge fan of user stories, wouldn't a short abstract or overview be better/reusable? 17:03:15 kaeso: perhaps. in short we want some document that clearly helps us understand what Fedora CoreOS is and what it is not 17:03:28 if user stories aren't the most appropriate way, then we'll do something else 17:03:30 +1 to avoiding a decision on format for now :-) 17:03:47 I don't think the format is the critical piece here 17:03:51 agree 17:04:00 moving on to next ticket in 30 seconds 17:04:07 ack 17:04:29 #topic Containers building and delivery ? 17:04:35 #link https://github.com/coreos/fedora-coreos-tracker/issues/8 17:04:39 ok some history here 17:04:57 in the old Fedora Atomic Working group, we also helped bootstrap the container effort in Fedora 17:05:15 so we would discuss app container or container build/infra issues in that issue tracker 17:05:27 that is NOT what we have to do here 17:05:37 but it's an option 17:05:52 I discussed with cverna earlier if we should break out the container effort into it's own group 17:06:02 so we may choose to do that 17:06:35 so questions 17:06:51 1 - how do people feel about discussion fedora container issues here (might be distracting) 17:07:13 I think it is mostly relevant for container like kubernetes etc ... 17:07:14 2 - depending on #1, who is interested in being part of a container group within fedora ? 17:07:27 1. seems out of scope? 17:07:33 I would like to deliver the CoreOS build tools as a container 17:07:48 +1 for a dedicated container group 17:08:00 I'm very much of the opinion our build process should use modern containers (not mock/koji) 17:08:22 walters1: I agree, but I don't know if that is the question at hand? 17:08:29 yeah, dedicated group, its related but seperable 17:09:00 +1 for build tools in a container 17:09:30 +1 for that, too 17:09:53 ok - so sounds like some separation would be ideal 17:10:06 how much separation may be a different story 17:10:30 #action cverna work with dustymabe to try to figure out a good strategy for containers working group going forward 17:10:36 cverna: what do you think ? 17:10:37 walters1, modern containers like? Any example name? 17:11:05 Will fedora coreos be releasing app containers for end users, or is that out of the project's scope? 17:11:12 dustymabe: sounds good to me, I agree a container wg or sig would be better :) 17:11:30 geoff-: i think "fedora" will be releasing app containers for end users 17:11:49 geoff-: based on the above I would say that it is out of scope 17:11:50 dustymabe, cverna: IMO this should also include the Modularity Containers peeps 17:11:53 and fedora coreos members can help with that effort, but i don't think it will be the responsibility of the WG 17:12:17 cverna: yes, let's get ttomacek and asamalik involved 17:12:32 dustymabe +1 17:12:34 ok, that's all the tickets with meeting tag for today 17:12:40 moving to open floor next 17:12:41 regarding what walters1 was talking about: I want FCOS's build process to be distro independent 17:12:46 flock might be a good time to start this :) 17:12:57 cverna: indeed 17:13:01 #topic open floor 17:13:07 cverna: I'm going to be there! Who else is? 17:13:07 anyone with anything for open floor 17:13:31 Anything the old Atomic WG members can do to help the new coreos wg? 17:13:34 dustymabe: process question - are you going to remove all meeting tags and link minutes afterhand? 17:13:58 I am asking for myself, as a Fedora volunteer contributor. 17:14:01 lorbus: I'll 17:14:19 kaeso: nice! 17:14:39 kushal: mainly just be involved in discussions. we don't have any bits yet, but there will definitely be work to do on that soon 17:14:58 kaeso: if meeting issues can be resolved we'll close them with an explanation 17:14:59 ajeddeloh: distro...like fedora vs centos, or support being run from an e.g. Ubuntu host? both? 17:15:05 if they can't be closed then they stay open 17:15:28 * asamalik reads 17:15:45 dustymabe: ack 17:15:56 both, like I want to be able to dev FCOS from gentoo, even if that means doing it out of some kind of chroot/container type environment 17:16:01 .hello2 17:16:03 asamalik: asamalik 'Adam Samalik' 17:16:29 ajeddeloh: yep agreed 17:16:31 dustymabe: I'm happy to get involved and help with Modularity 17:16:36 ajeddeloh++ 17:16:41 walters1: historically, we had a good variety of linux distros and the SDK never enforced hard constraints on the host 17:16:50 asamalik++ 17:16:53 asamalik: more specifically modularity+containers, cverna will likely reach out 17:17:21 dustymabe: cool 17:17:38 dustymabe, asamalik: I'm definitely interested in helping out with that, too! 17:17:49 another thing I'd like to see: something like cros_workon for FCOS 17:17:52 geoff-: do you have any topics for open floor? want to intro yourself ? 17:17:58 as someone only mildly familiar with the SDK, I really like the concept 17:18:17 * dustymabe googles cros 17:18:47 for those unfamiliar with cros_workon, it lets us toggle from saying "I want to build the latest 'release' for some package" to "I want to build the source sitting in my local directory" 17:19:00 dustymabe: tldr building an image with all official bits, except for something taking from a local dir/git 17:19:19 got ya 17:19:22 would be interesting if the FCOS SDK was something you deploy in `oc cluster up` 17:19:27 s/taking/taken/ 17:19:30 so if I'm testing a change in say systemd, I can make my changes locally, and build a new image with that change that's sitting on my host 17:19:53 well, I'm interested in having arm64 support... 17:19:58 jlebon: you mean can deploy like that or need to deploy like that 17:20:27 jlebon: I'm actually looking for something closer to local, i.e. just a containerized build environment 17:20:30 geoff-: +1 17:20:59 like almost everything in Fedora. We'll certainly try make FCOS available on aarch64 17:21:08 ajeddeloh: I guess need to? the idea being that it matches exactly how production images are created 17:21:22 hmmmmmm I'm not sold on that 17:21:28 if this makes you feel any better we offer Fedora Atomic Host on x86_64 aarch64 and ppc64le today 17:21:53 jlebon: requiring OpenShift to do FCOS development seems like a layering violation :-) 17:22:03 jlebon: I don't want the build process to be dependent on external tools 17:22:15 s/tools/services 17:22:43 this is a bit of a rathole discussion, but... `oc cluster up` runs on your laptop 17:22:50 like I want to be able to run the build locally, fetching cached builds if necesarry 17:22:56 i'm not for requiring it, just noting 17:23:06 i'm thinking more higher level. if the production pipeline is fully described by a set of openshift resources you can run locally, that's pretty powerful 17:23:25 jlebon: yeah, alignment is nice 17:23:38 With CL all of the build tools run locally, and the official release process is basically those same tools running in jenkins 17:24:12 which is something I'd like to see with FCOS 17:24:20 ok mostly rathole, maybe we can discuss in an issue ? 17:24:29 It's easy to compose an ostree locally 17:24:29 +1 17:24:38 You'll need to build the rpms 17:24:49 jbrooks: i think the point is not having to build the rpms 17:25:01 i.e. the SDK picks up those changes you made to local changes on your FS 17:25:05 sort of tangentially related to this is that i really, really dislike the one-git-repo-per-package model fedora has and I think it's an impediment to better tools (related to cros_workon) 17:25:07 and then composes the full artifact 17:25:09 I mean the _whole_ process, from source > rpms > ostree > bootable image 17:25:10 dustymabe: just as a note, this is the same kind of topic we were discussing yesterday (re imagefactory+anaconda) 17:25:26 dustymabe, but it'll still be based on rpms, right? 17:25:47 jbrooks: yes, it's the in between steps that would need to be optimized 17:26:00 kaeso: yes 17:26:17 It seems that a process like what Colin worked out for centos continuous would work 17:26:38 rpmdistro-gitoverlay 17:27:00 And the tree and images can be built w/ those rpms, all locally 17:27:17 jbrooks: that's what is currently used, the point of discussion is containerizing and the UX for OS developers 17:27:18 ok 3 minutes left in meeting 17:27:27 oh yeah, I wasn't here last time. hi all, I'm Benjamin Gilbert. I work on Container Linux and now Fedora CoreOS. 17:27:29 any last minute topics ? 17:27:44 COLLECTIVE: "hi benjamin" 17:27:49 bgilbert++ 17:28:01 dustymabe is in a hurry^^ 17:28:05 bgilbert, hello 17:28:10 bgilbert: is awesome FYI 17:28:14 bgilbert: that looks like a pretty bad addiction ;) 17:28:27 * bgilbert waves 17:28:29 bgilbert: hi! nice to meet you 17:28:32 re: arm support: we should _actually_ test arm from the start 17:28:50 like as a first class citizen 17:29:01 ajeddeloh: +1 17:29:06 geoff-: mind joing #fedora-coreos? 17:29:10 *joining 17:29:13 ajeddeloh: yes 17:29:38 I'd like to see a proposal for the build tooling/build system. Maybe start something in the issue tracker. 17:29:39 especially since fedora's arm packaging is better than gentoos in general (from what I understant) 17:29:52 geoff- ++ 17:30:09 geoff- +1 17:30:11 yes, arm is generally a first class citizen in Fedora (for Server) 17:30:35 maybe start with what we want out of our build system / tooling, ignoring what we have already 17:30:35 but I will note that we will probably start with x86_64 and while we are experimenting with build pipeline 17:30:51 then add aarch64 17:30:57 then figure out what bits we already have, what bits need work, what bits need to be build 17:31:31 ok we're over time. I'm going to close this out 17:31:40 thanks for hosting dustymabe! 17:31:40 if anyone has any outstanding topics please add to the issue tracker 17:31:44 #endmeeting