16:02:13 #startmeeting atomic-community 16:02:14 Meeting started Mon Oct 30 16:02:13 2017 UTC. The chair is jbrooks. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:02:14 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:02:14 The meeting name has been set to 'atomic-community' 16:02:14 Meeting started Mon Oct 30 16:02:13 2017 UTC. The chair is jbrooks. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:02:14 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:02:23 #topic roll-call 16:03:10 #chair dustymabe ashcrow jberkus 16:03:10 Current chairs: ashcrow dustymabe jberkus jbrooks 16:03:10 Current chairs: ashcrow dustymabe jberkus jbrooks 16:03:18 .hello jberkus 16:03:21 jberkus: jberkus 'Josh Berkus' 16:03:41 .hello tsweeney 16:03:42 tsweeney: Sorry, but you don't exist 16:03:45 .hello dustymabe 16:03:46 dustymabe: dustymabe 'Dusty Mabe' 16:03:55 .hello smilner 16:03:56 .hello walters 16:03:56 ashcrow: smilner 'None' 16:03:59 walters: walters 'Colin Walters' 16:04:02 .hello miabbott 16:04:03 miabbott: miabbott 'Micah Abbott' 16:04:17 #chair walters miabbott 16:04:17 Current chairs: ashcrow dustymabe jberkus jbrooks miabbott walters 16:04:17 Current chairs: ashcrow dustymabe jberkus jbrooks miabbott walters 16:04:31 #topic action items from last mtg 16:04:44 .hello ttomecek 16:04:46 ttomecek: ttomecek 'Tomas Tomecek' 16:04:52 .hello jlebon 16:04:53 jlebon: jlebon 'None' 16:05:05 #chair ttomecek jlebon 16:05:05 Current chairs: ashcrow dustymabe jberkus jbrooks jlebon miabbott ttomecek walters 16:05:05 Current chairs: ashcrow dustymabe jberkus jbrooks jlebon miabbott ttomecek walters 16:05:25 jberkus, did we meet on the 16th? Or was the 2nd the last? 16:05:48 Oh, I see the 16th minutes 16:06:03 jberkus to open a ticket about container runtime inclusion 16:06:14 that exists, lemme find it 16:06:47 https://pagure.io/atomic-wg/issue/360 16:07:00 * dustymabe has a feeling there are some action items the he forgot about 16:07:03 so, currently we're at stalemate 16:07:04 #info last meeting's minutes: https://meetbot.fedoraproject.org/atomic/2017-10-16/atomic-community.2017-10-16-16.02.html 16:07:17 1) we don't want to NOT include Docker in the base image because users like it 16:07:39 2) but we don't want to include Docker and exclude CRIO because that implies we don't trust CRIO 16:07:49 3) but we don;t want to have both because disk space 16:08:06 rock, paper, scissors 16:08:09 And this is for Fedora 28, right? 16:08:16 When would we need to decide by? 16:08:23 and evenutally everything else, presumably 16:08:48 jbrooks: I don't know if there is a hard date for that 16:09:01 Agreed, I am not aware of a date 16:09:05 but I'd like to know the strategy sooner than later. will make it a smoother transition 16:10:26 OK, well, to be continued, I suppose 16:10:33 well, one way to resolve it is to survey users to find out how much (1) matters 16:11:10 jberkus: I like the idea. Do we think we'd get a good enough response sample? 16:11:36 ashcrow: one way to find out ... 16:11:41 jberkus: i'm +1 16:11:48 +1 16:11:56 #action jberkus to create survey around container runtimes 16:12:04 Cool 16:12:26 one thing is users of cri-o will generally be kube users, so those should go together right? 16:12:28 the other part of (1) is to work with dwalsh's team on making the "install system container" command simpler 16:12:43 walters: so make CRI-O install part of Kube install? 16:13:20 a big picture question here is the degree to which cri-o is used for single node/non-orchestrated cases 16:13:31 .hello jberkus 16:13:35 whenry: jberkus 'Josh Berkus' 16:13:40 making it part of the installer is reasonable 16:13:41 heh 16:13:45 .hello whenry 16:13:46 whenry: whenry 'William Henry' 16:13:58 #chair whenry 16:13:58 Current chairs: ashcrow dustymabe jberkus jbrooks jlebon miabbott ttomecek walters whenry 16:13:58 Current chairs: ashcrow dustymabe jberkus jbrooks jlebon miabbott ttomecek walters whenry 16:14:01 but implies that we prioritize docker over crio if we leave it out and totally up to the installer 16:14:11 so that's tricky \ 16:14:15 Or leave both out 16:15:01 that sounds like an unfortunate OOTB experience 16:15:02 Leaving docker out of the image gives ppl the option of running the docker they want, which is sometimes the upstream one 16:15:04 well, one of my questions about built-in Docker is "which version"? 16:15:06 as a user of atomic I'd prefer not to do that 16:15:20 jberkus: whatever version is shipped in Fedora 16:15:23 I don't think it's actually possible to include a version of Docker which will satisfy more than 1/3 of our users 16:15:29 To me, atomic w/o kube or origin isn't too interesting 16:15:30 if you want a different version then use a system container 16:15:39 of course *this* discussion crosses into Modularity 16:15:54 A worthwhile atomic requires some install and config anyway 16:16:14 walters: now, *that's* a good quesiton. Can someone find out how modularity impacts this? 16:16:44 here's something to consider: F27 Atomic will include an ARM version, and CAH and RAH will later 16:17:04 given that, we're going to have users who want Atomic for the IoT use case 16:17:13 jberkus, in a modularity world we'd build e.g. multiple upstream kube versions 16:17:18 rather than one-per-fedora-major 16:17:29 do *those* users want a built-in Docker? 16:17:38 I suspect not 16:18:13 jberkus: so this is another question altogether to be honest 16:18:36 obviously we are getting to the point of trying to apply atomic host (the actual ostree we ship) to many many different use cases 16:18:45 once you step over into IOT I think we've gone too far 16:19:00 ? 16:19:00 * dustymabe thinks we'll probably have to have a different ostree definition that we ship for something like that 16:19:07 possible 16:19:34 but right now the IoT users I talk to are just asking for a smaller base image 16:19:39 and ... auto-rollback 16:20:20 it vanilla fedora (is that nasty) there are desktop, server, cloud versions. perhaps for Atomic there is server and iot versions (?) 16:20:37 I think we have to focus a bit on our prime audience for now, but I do want to see us making a smaller base as we can. 16:20:52 use ostree to spin different flavors of atomic 16:21:15 whenry: that certainly is a possiblity 16:21:25 ashcrow: I agree. we need to focus for now probably 16:21:26 * whenry thought that that was one of the early goals 16:21:30 Is single node, ready out of the box a real use case we're targeting? 16:21:34 whenry: I follow what you mean, but I'm not sure that makes it much easier for users. They already have Fedora desktop, server, cloud (and spins of those) Add AH with different spins for different uses and it may be too much choice (confusing). 16:21:44 jbrooks: i'd like to think so 16:21:58 otherwise why did we ever ship docker included to begin with? 16:22:10 or bake anything else into the host 16:22:10 ashcrow: ack.. but how many flavors of atomic? 16:22:13 Because that was *the* container engine 16:22:27 layering wasn't an option, system containers weren't an option 16:22:29 also, we didn't have system containers 16:22:43 and we couldn't install rpms 16:22:49 so that's why 16:23:34 All right, we have the survey as a next action 16:23:58 We can find out which ppl prefer -- small image and flexibility, or out of the box docker 16:24:00 well, someone else should volunteer to talk to Fedora/RH modularity and find out if our decision here is affected by that 16:24:33 and someone else should work with walters/dwalsh about having a simpler command for installing system containers 16:24:37 walters: ? 16:25:03 jberkus: that's in the works already as a known issue with giuseppe and I. 16:25:12 Making the install command for system containers less verbose. 16:25:25 yeah, i agree to focus on the system containers more 16:25:52 i still think that simplifying the command isn't going to solve the problem 16:26:00 +1 walters and ashcrow 16:26:09 dustymabe: I think it's a side thing, not a fix for this specific issue 16:26:17 ok 16:26:30 IE: it should happen no matter what as it's too verbose as it is 16:26:58 Here's a thing to consider, too, our docker version is getting older and older 16:27:05 And we only rev to serve kube 16:27:28 see above re: "there is no version of Docker which will satisfy more than 1/3 of the user base" 16:27:30 Therefore, the built-in status quo is getting less useful to ppl looking for a docker-enabled host 16:27:50 in fact, it's getting in the way of them layering on what they do want 16:27:56 that's gotten worse since moby, too 16:28:24 jbrooks: you can't run a system container of docker with the other one installed as an RPM? 16:28:36 dustymabe, who's going to make the system container? 16:28:41 The user? 16:28:44 .hello jligon 16:28:45 jligon: jligon 'Jeff Ligon' 16:28:51 jbrooks: side note that one can `rpm-ostree ex override replace` nowadays, which definitely works with docker 16:29:01 Ours only includes the ones we're already baking into the image 16:29:05 I do remember a possible design session was proposed last week. Maybe we should go ahead and schedule one so those who feel strongly for both end results can propose their idea(s)? 16:29:08 jlebon, good point 16:29:40 jbrooks: whoever needs the specific version 16:29:47 jbrooks / dustymabe: You can run system container of docker with docker installed as an rpm 16:29:51 ashcrow: seems like a good idea 16:30:14 i'm just saying we can't force our maintainers to support many different versions of docker if they don't want to 16:30:37 it's up to the user mainly, but they have the flexibility for that if they need it right? 16:30:37 Ok, but if we're worried about being easy for users, making them create their own system container isn't an easy option 16:30:55 jbrooks: right, but why is our version of docker so bad? 16:31:07 it's permanently old 16:31:11 i realize it's older, but i think that is a problem that works itself out over time 16:31:23 i.e. docker becomes more stable and less new hotness goes in there 16:31:24 We don't care about docker on its own, just docker as kube engine 16:32:00 jbrooks: is that really holding us back in a lot of cases? 16:32:15 If we're worried about giving people docker 16:32:18 ok fellas, we're 31 minutes in, dustymabe do you mind setting up a design meeting to go over just this as a group? 16:32:24 it feels like there's not much use pursuing this without survey/usage data 16:32:26 We should be better stewards of docker 16:32:44 But we aren't actually worried about that, we're worried about making a node OS for origin and kube 16:32:56 do we have any other topics for this meeting, BTW? CAH? 16:32:57 And that's where our attn is focused 16:33:07 I can give a CAH update 16:33:12 btw one variable in this is I really find `oc cluster up` super useful and today that talks to docker 16:33:14 ashcrow: mabe 16:33:18 maybe :) 16:33:44 And f28 seems a long way off ;) 16:33:48 walters: it does? 16:34:06 i'm not sure if there's been any cri-o work for that 16:34:45 jbrooks: do we have any other items to talk about today? If not, then let's continue this one. 16:35:10 ashcrow, I want to give a centos atomic update 16:35:32 #topic CentOS Atomic Host update 16:35:50 walters: pretty sure that oc cluster up embeds its own docker 16:36:17 We haven't released the update for this month, 1709 -- it was held up for a long time on build issues, and it actually is still held up, working w/ KB on this 16:36:39 We might end up skipping to 1710 16:36:59 jbrooks: KB? 16:37:27 Karanbir Singh, of CentOS fame 16:37:31 ahh 16:37:32 ok 16:37:49 There's a signed tree for 1709 here: https://buildlogs.centos.org/centos/7/atomic/x86_64/repo/ 16:38:03 That's what we would release, but we're held up on images issues 16:38:11 at the moment 16:38:29 +1 on skipping to 1710 16:39:16 And, one other centos atomic note -- we changed our meetings to accommodate more time zones, but we haven't actually had anyone attending our alternating meeting 16:39:39 So we should maybe rethink that 16:39:50 That's all from centos currently 16:40:00 #topic open floor 16:40:25 Any more discussion desired on baked-in docker? 16:41:07 We have 20 minutes left, I suggest we keep talking. If we don't come up with a plan in 20 then we schedule a design session/debate. 16:41:41 I have a couple items 16:41:42 I'd agree, but would like to have dwalsh in on that debate. 16:41:56 One: we will have a contianer day at SCALE 16x in Los Angeles, March: http://www.socallinuxexpo.org/scale/16x/cfp 16:42:08 I'm on the committee. Unfortunately, deadline is tommorrow 16:42:48 jberkus, Ah, so that's separate from the main show? 16:42:59 yeah, but submissions are handled together 16:43:09 more general stuff will go into the weekend talks 16:43:17 more in-depth stuff will go into the Container day 16:44:22 going back to crio, right now their site doesn't seem to mention AH: http://cri-o.io/ 16:45:26 but it could. what would we like it to say? 16:45:28 feels like an outcome from this discussion is a fix for that? 16:46:31 * whenry wants to discuss something at the end :) 16:46:34 jligon / walters: At least instructions similar to the one for fedora 16:46:41 under "Try now" 16:46:56 * walters thinks AH is also Fedora but that's another thing ;) 16:47:09 walters: true :-) 16:47:11 I'm still working on a blog post about cri-o and atomic 16:47:29 A section under fedora via System Containers then 16:47:32 jberkus: tutorial on buildah for containerday :) 16:47:53 +1 16:48:04 whenry: dwalsh submitted a talk. you're welcome to submit one too ... you tend to be more new-user-approachable 16:48:40 * whenry wants to understand if we can expect #299 and #302 to pass soon. Some sort of rpm issues. (nothing to do with my docs/tutorials/01-intro.md add.) 16:48:52 (a deep issue here of course is "Fedora" also covers workstation which is a lot more popular use of Fedora) 16:48:57 jberkus: :-) 16:49:26 walters: / ashcrow I'm really good at proofreading and testing out instructions for AH and cri-o, but not so good at generating them. 16:50:12 For the system containers, I'd really like to be able to use the projectatomic docker namespavce 16:50:19 and I can edit cri-o.io 16:50:35 My writeup is just using my docker namespace 16:50:40 Not very legit 16:51:12 that gets into the FLIBS vs CentOS CP discussion too right? 16:51:16 jligon: I'll write something up later this afternoon and send it your way. 16:51:52 walters, yes, though I think there's a place for all three 16:52:39 whenry, is that Buildah #299 and #302? If so, I'm runnning those down this pm. 16:53:15 it feels to me like syscontainers should be CentOS based, though...not to go too far down the rabbit hole (ok actually I really am) that also shouldn't meant they can't be built in FLIBS... 16:53:40 tsweeney: ack yes 16:54:14 +-++++++++++++++++++++++++++++++`+++ 16:54:33 walters, for docker and for cri-o, in the system-atomic-containers repo, there are separate centos and fedora dirs, do those really need to be separate? Could the centos-docker or crio work on fedora? 16:54:43 tsweeney: sorry it's been a while since I committed stuff to atomic so I forget that it's more than just atomic but sub projects too . 16:54:46 ooops, sorry, lol was found a dust kitty I was trying to dig outta my keyboad. 16:55:02 whenry, You have an item to raise as well? 16:55:03 jbrooks: centos can work on fedora. Fedora generally works on centos/rhel. 16:55:07 jbrooks, the origin containers pulled down via `oc cluster up` use centos 16:55:19 whenry, no worries. 16:55:43 jbrooks: I've already reached out to dwalsh. He mentioned I should blog the tutorial too. I was wondering where we want that to be blogged 16:55:52 walters, I've run cent and fedora based kube on each other, I wondered if it was different for the runtimes 16:56:09 jbrooks: the buildah blog 16:56:27 s/blog/tutorial/ 16:56:34 whenry, seems like a fit for the project atomic blog 16:56:39 there's definitely a long term issue using fedora userspace on centos around syscalls; e.g. many times in the past glibc has bumped their minimum kernel version 16:56:43 jbrooks: for system containers it's more so related to systemd, runc, and caps 16:56:58 jbrooks: so who manages that? 16:57:06 but OTOH the prevalence of containerization now is going to force most userspace apps that do advanced syscalls to "try and fall back" i imagine 16:57:11 whenry, jberkus -- you can send a PR 16:57:24 for e.g. getrandom() 16:57:29 whenry, there was a previous post there https://www.projectatomic.io/blog/2017/06/introducing-buildah/ 16:57:35 jbrooks: ack. jberkus and I are already talking. great! 16:57:41 cool 16:58:49 jbrooks: ack. I remember that one too. I'll coordinate with jberkus and tsweeney 16:59:31 for those that want to look over this one see: https://github.com/projectatomic/buildah/pull/302 :) 16:59:40 +1 17:00:02 OK, ready to wrap up? 17:00:15 jbrooks: it's for simple folk, like me ;-) 17:00:21 :) 17:00:26 ack. thnx 17:00:36 #endmeeting