16:00:23 #startmeeting containers 16:00:24 Meeting started Tue Nov 11 16:00:23 2014 UTC and is due to finish in 60 minutes. The chair is adrian_otto. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:25 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:27 The meeting name has been set to 'containers' 16:00:28 #link https://wiki.openstack.org/wiki/Meetings/Containers#Agenda_for_2014-11-11_1600_UTC Our Agenda 16:00:35 #topic Roll Call 16:00:40 Adrian Otto 16:00:49 Jesse Butler 16:00:51 Digambar Patil 16:01:21 Davanum Srinivas (dims) 16:02:04 our attendance is likely to be a little thin because I did not have a current meeting schedule on the wiki until this morning 16:02:19 yep 16:02:28 my apologies about that 16:02:49 NP 16:03:03 we will begin in just a moment 16:03:15 ok 16:04:30 also, DST has ended in North America making the meeting one hour earlier than usual in US timezones. Attendance is always light when that happens. 16:04:33 Morning all. 16:04:43 hi kitch_ 16:05:12 good morning everyone. 16:05:26 ok, so although Roll Call is done, you are welcome to chime in at any time to record your attendance. 16:06:00 I see we have some new Stackers present today, so I will give you a chance to introduce yourselves before we discuss the main agenda topics. 16:06:05 #topic Announcements 16:06:10 1) Stackforge repo now open 16:06:16 #link https://github.com/stackforge/magnum Magnum Repo 16:06:39 This was the compromise struck last Thursday from the Design session I will summarize in a momnet 16:07:17 Until we determine whether this will continue as an OpenStack compute program effort, or be handled separately, this is where we can collaborate on source code. 16:07:22 * adrian_otto applause 16:07:27 :) 16:07:40 Any other announcements from team members? 16:07:53 * kitch_ cheers 16:08:17 #topic Review Action Items 16:08:23 drian_otto to attempt to identify Linux kernel patches that could enable use of nested containers in non-privileged mode 16:08:34 *adrian_otto 16:08:46 so I actually did find the code for this, and bookmarked it 16:08:53 one moment while I get the link 16:09:18 ok 16:10:37 darn, I can't find it 16:10:45 I'll carry that action item to next week 16:10:57 #action adrian_otto to attempt to identify Linux kernel patches that could enable use of nested containers in non-privileged mode 16:11:16 I am confident that this work is in progress, and that patches do exist 16:11:37 #topic New Attendees 16:11:43 we are growing our team 16:12:11 there was considerable interest in Magnum in Paris, and we will have more Stackers starting to work with us 16:12:42 * kitch_ waves 16:12:52 those of you who are new today are welcome to introduce yourselves to the team now. You can share your name, any employer info, and your area of interest (operator, developer, product manager, etc.) 16:13:35 Navid Shaikh(nshaikh), Red Hat, developer. 16:13:48 hi there, i'm jesse butler. i work in the core solaris engineering org at oracle, on the virtualization team. i'm working on modernizing our lightweight containers for use with openstack (and possibly docker). 16:14:22 welcome kitch_ nshaikh and jlb13 16:14:29 * jlb13 waves 16:14:38 thanks, it was good to meet you last week 16:14:49 Jake Kitchener, IBM CTO Office for Software Defined. Primary focus is on acceleration of future technology. We’ve mainly been focused on consumption and driving our openstack upstreamers. Trying to take a more vested role around containers 16:14:53 indeed. I am very happy to see you here. 16:15:16 thanks! nice to meet you 16:15:17 thanks kitch_ 16:15:31 Hi kitch_ 16:15:37 so we have a ton of fun work to do in this area 16:15:57 so let's cover a bit of what happened in Paris 16:16:06 I know diga is itching to hear about that 16:16:08 adrian_otto: great! 16:16:11 yes 16:16:14 #topic Paris ODS Summary 16:16:18 :) 16:16:19 Hope you had a great summit ! 16:16:23 I led two sessions about Magnum at the Paris Summit. One was actually at the Ops summit, and the other in the Nova track at the Design summit. 16:16:42 both of these taught me something important 16:16:56 let's dive into each 16:16:57 #link http://kilodesignsummit.sched.org/event/9f47bddfffa9a1907f2334fa412afaf4#.VGIth-cl5Eg Ops Summit: What do we want from containers/docker? 16:17:03 Key Takeaways: 16:17:09 1) OpenStack operators definitely want containers as a first class resource in OpenStack, with advanced containers-specific features that can not be offered by a Nova virt driver. 16:17:24 The room was *very* full 16:17:31 right. 16:17:52 I was told by some attendees that it was at capacity, and there were Stackers in the lobby who were not permitted to enter due to max occupancy 16:18:05 so that alone told us something 16:18:23 all of the containers related sessions all week on all related topics were very well attended 16:18:30 For those that didn’t attend, this was true of EVERY session related containers 16:18:38 indeed. 16:18:42 agreed. if it had "docker" or "container" in the topic, it was packed. 16:18:44 adrian_otto: Could you Pl provide with the link of the containers sessions. 16:19:06 Great response 16:19:08 nitin: ther eis a link a few lines up, did you see that one? 16:19:29 I'm about to give you a second one in a moment (you can check the agenda if you want them sooner) 16:19:47 yes I have seen that. 16:19:49 Ok 16:19:53 In this particular session I explained the concept of Magnum and how it would work 16:20:19 and toward the end I polled the audience to find out if the interest was just for Docker, or for other container types as well 16:20:22 2) There is considerable interest for support for both Docker and libvirt/LXC. There was no interest expressed in OpenVZ, although Rackspace does value that. 16:20:53 roughly 70% of the room would be happy with a solution that only addressed Docker compatibility 16:21:12 at least 15-20% were also interested in LXC support 16:21:29 but there did not seem to be a ton of overlap between those two groups 16:21:33 there seemed to me to be a bit of confusion regarding a docker-like API design, and just "using docker". 16:21:49 yes, anyone could just use docker today if they want 16:21:58 for our purposes in solaris (and likely james' team's purposes with openvz) a docker-like api would be just fine. 16:22:33 one thing that was very clear after this session was that something modular for openstack would be valued, especially if it would work well with Docker 16:22:45 and agreed - there is interest in containers as an os resource, and in docker. not a lot of overlap, seemingly. 16:22:53 so that really confirmed our gut feelings about this 16:22:55 yes, that was my overall takeaway as well 16:23:18 jlb13: *nod* 16:23:45 so there was some perplexed users who did not understand why nova-docker was out of tree 16:24:03 I did discuss that with Ian Main 16:24:32 and suggested that it continue in Stackforge, but that on milestone releases, it gets imported into the Nova tree as a driver. 16:24:53 ok 16:24:55 that way they can still innovate quickly, and operators can leverage it easier 16:24:58 adrian_otto: there's a black list of tests that needs to work before that - https://bugs.launchpad.net/nova-docker/+bug/1391233 16:25:00 Launchpad bug 1391233 in nova-docker "Enable black listed tests in tempest" [Undecided,New] 16:25:17 dims: acknowledged. That list is being worked 16:25:28 my understanding is that several of the key items have already been addressed 16:25:50 so there is a good chance it could come back into tree soon 16:26:50 my reason for spending time talking about this is because if you care about Magnum, you should also care about nova-docker, as it's likely to be the default virt driver for our tempest tests 16:27:12 otherwise our CI could take a really long time to run 16:27:22 hmm 16:27:32 ok, so circling back to the summit sessions 16:27:35 the next one: 16:27:36 #link http://kilodesignsummit.sched.org/event/4ea895d62545e557991dfc5b7405ceb9#.VGItOucl5Eg Containers service (magnum) 16:27:44 This was in the Nova track 16:27:49 Key Takeaways 16:27:53 ok 16:27:56 1) Commitment to resolve the quarrel over what sort of a code repository we use. A stackforge repo was finally opened as an action item. 16:28:16 I announced the link to the repo in the Announcements section above 16:28:27 this took the bulk of the discussion time 16:29:01 a small number of Nova cores (confirmed again to be a small minority) don't want to be distracted from what Nova is now 16:29:23 they had been blocking my patches to add a repo to the openstack namespace 16:29:41 and others (confirmed to be a majority) believed that it belonged in the compute program 16:29:48 and were blocking it from going into stackforge 16:30:08 Good 16:30:15 Michael Still higlighted this, and insisted that we get some repo open 16:30:24 we did. 16:30:32 so that's solved for now. 16:30:38 Just a note... 16:30:45 at least something we have in hand now officially 16:30:48 It sounded to me like the main issue here was chicken and egg. 16:31:04 related takeaway: 16:31:05 2) The Nova team wants to focus primarily on improving the existing Nova code, and is happy to allow a new team to form around Containers. 16:31:12 Magnum is difficult to launch without being part of compute. Compute is worried about the overhead of a project that is VERY new 16:31:27 kitch_: yes, exactly. The OpenStack community has not figured out how to innovate from scratch yet. 16:31:50 my attempts to do this (twice now) have been met with lots of confusion and resistance 16:32:22 so the way to combat this is to make Magnum really easy to get and use, and make the user experience really smooth 16:32:37 It doesn’t feel like Stackforge is the wrong place to start, but it would be good to get a * on the project that shows it’s got a path to core 16:32:58 if users like it, the rest should work out naturally over time 16:33:11 if users hate it, then we can move on to something different 16:33:31 meanwhile, docker is getting better 16:33:33 +1, sounds like a good plan 16:33:42 +1 16:33:59 +! 16:34:03 so even if we try and fail here, it's not like there won't be any good containers story to fall back on 16:34:29 next key takeaway: 16:34:31 3) I asked for members of the audience to indicate to me if they wanted the Magnum effort to stop or continue. I was swarmed with Stackers wanting to get involved, and nobody contacted me after the meeting indicating we should stop. The feedback was strong, encouraging and positive. 16:34:47 I was expecting at least one stacker to come and say this is a distraction. 16:35:10 that did not happen. The only resistance was shown during the session with all of us as witnesses. 16:35:29 all of the after-session feedback was strong encouragement 16:35:35 Good 16:35:39 Good! 16:35:43 point, I don’t think that containers + openstack is a disctraction, and magnum is as good a proposal as any, but I do think we need to watch the docker community closely to ensure this is the right intersection. 16:35:46 so this mirrored the sentiment from the Ops session 16:35:52 We’re chasing an extremely fast moving target. 16:36:12 kitch_: yes that's a legitimate concern 16:36:34 I believe we even talked a bit if openstack is the right place to do this or more in partnership with docker 16:36:34 I can assure you that I'm following both, and participating in the work that's happening in the Docker community 16:37:09 ok 16:37:23 yes, if the goal were just to make DOcker and OpenStack to work better together, Magnum would not be needed 16:37:38 but our goal is to make containers (modular) to work well with OpenStack 16:37:51 yes 16:37:52 so that's a bit different 16:37:56 i'm glad to hear you make that statement 16:38:23 +1 16:38:48 so we need to welcome those like jlb13 who have non-docker container tech that they can help us surface in OpenStack 16:39:00 not every use case will be perfectly served by Docker 16:39:12 and the user community has clearly indicated that they want choice. 16:39:15 as well as lxc-only users, openvz and others 16:39:45 yes, and openVZ developers are willing to contribute to Magnum, as well as LXC guys from Canonical 16:40:10 adrian_otto: Did you by chance talk to anyone from Canonical about LXD? 16:40:14 right, lxd is the first likely peer to docker. that should help frame things. 16:40:35 so with Parallels, Oracle, Canonical, and Docker working together, we are likely to come up with a good system for a Containers API 16:40:48 * jlb13 cheers 16:40:57 jlb13: good point. lxd is new from Canonical 16:41:34 works at the level of functionality of a virt driver (like nova-docker) and makes LXC available as a way to make smaller, more efficient OS image containers 16:41:50 there is no concept of layering in there… at least not yet. 16:42:12 nod. high level it abstracts container creation and lifecycle management. so, it's "above" container primitives. 16:42:15 on Friday Ian Main and Eric Windisch worked on a POC on Friday that aims to offer minimalistic end-to-end functionality to allow starting and stopping of containers on Nova instances. 16:42:42 we made a couple of line diagrams and Eric made some simple python code to illustrate the concept 16:43:03 I think his intent was to put that into the stackforge repo for discussion 16:43:40 his IRC client is idle now, so we'll have to follow up on that later. 16:43:47 adrian_otto: Steven Dake has 10 commits in his repo over diga's repo - https://github.com/sdake/magnum 16:44:18 I just noticed that about a minute before we started our team meeting today 16:44:19 i spent last evening looking at that and threw in one more commit - https://github.com/dims/magnum 16:44:40 it probably makes sense to move that code into the Stackforge repo 16:45:12 I will be putting the spec review in there, and abandoning the one from the nova-specs repo 16:45:18 #topic Open Discussion 16:45:48 our next steps will be to put detailed docstrings into the stackforge repo to document the API 16:46:01 Thanks you guys spending time in improvement of the API code 16:46:03 review those in Gerrit to the point we feel good about them 16:46:14 and then begin to implement the API based on the docstrings 16:46:18 does that make sense? 16:46:23 yep 16:46:28 y 16:46:29 +1 16:46:30 +1 16:46:30 +1 16:46:45 +1 16:46:53 then connect the API to an agent to demonstrate end-to-end capability 16:47:05 we *could* use the docker daemon as an agent as a first step 16:47:14 ok 16:47:52 we do have a BP for an agent 16:48:31 https://blueprints.launchpad.net/magnum/+spec/magnum-agent-for-nova 16:48:33 #link https://launchpad.net/magnum Our LP Page 16:48:39 tx diga 16:48:43 :) 16:49:13 i think (very high level) if we have an API defined which is roughly based upon docker functionality, and we have it driving the docker daemon at the backend, it seems like a good milestone to prove end-to-end in that context 16:49:20 our proposed design for the agent will work for control plane, but will not be suitable for serial console capability (ala docker attach) 16:49:45 jlb13: ok, good so we agree on that 16:50:08 we might consider allowing for agent types 16:50:14 so docker may be one type 16:50:23 ok 16:50:33 and magnum's reference implementation of the agent might be another type 16:50:42 and we could see what operators prefer 16:50:56 maybe better ones can emerge that way 16:52:00 having agent types would be good thing for future 16:52:20 so agent types, and docker being a type, does that indicate there could be multiple docker agent implementations? 16:52:55 sounds more like multiple magnum agent types, docker being one type 16:53:00 or maybe someone wants to run lxd 16:53:04 that would be another type 16:53:08 yes, 16:53:08 ok, so one to one mapping between type and agent 16:53:19 or a zones agent on solaris, or a joyent one on smartos, etc 16:54:30 so conceptually I see that as a pluggable back-end for Magnum 16:54:41 nod. 16:54:57 so we are approaching the end of our scheduled time 16:55:06 any other topics that you'd like to address today? 16:55:17 we'll have to define fairly early on core requirements of a backend, versus optional functionality 16:55:26 adrian: we need some help from marconi team for queue implementation 16:55:58 diga: you mean, zaqar ? :P 16:56:02 yes 16:56:09 whatever we can help with, please, let us know 16:56:19 sure 16:56:26 Thanks Flaper87 16:56:32 my pleasure :) 16:57:41 anybody is taking responsibility to migrate existing magnum repo to stackforge ? 16:58:30 i can do that specific task if needed 16:58:36 ok 16:59:32 adrian: will it be fine to migrate existing magnum repo to stackforge ? 16:59:34 alright, so our next meeting will be UTC 2200 Tuesday 2014-11-18 16:59:35 we'll need to add some ci jobs 16:59:41 diga: yes. 16:59:50 ok 17:00:12 looks like we will have plenty to talk about then. Please idle in #openstack-containers in the mean time 17:00:16 #endmeeting