22:01:04 #startmeeting containers 22:01:04 Meeting started Tue Jul 1 22:01:04 2014 UTC and is due to finish in 60 minutes. The chair is adrian_otto. Information about MeetBot at http://wiki.debian.org/MeetBot. 22:01:05 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 22:01:08 The meeting name has been set to 'containers' 22:01:23 #link https://wiki.openstack.org/wiki/Meetings/Containers#Agenda_for_2014-07-01_2200_UTC Our Agenda 22:01:33 #topic Roll Call 22:01:38 Adrian Otto 22:01:42 Dmitry Guryanov 22:02:33 wow, everyone is on vacation today? 22:02:43 o/ 22:03:27 hi PaulCzar_ and dguryanov 22:03:38 I'll wait just a bit for others to join 22:04:36 Hello 22:04:43 hi iqbalmohomed 22:05:46 ok, let's proceed. 22:05:52 #topic Announcements 22:05:58 o/ 22:06:09 • Notice: adrian_otto will be on vacation 2014-07-11 to 2014-07-24. Seeking interim chair for 2014-07-15 and 2014-07-22 meetings. 22:06:21 would anyone like to volunteer to chair on those dates? 22:06:40 I do 22:06:48 thanks erw_! 22:07:05 #agreed erw_ will serve as chair for our 2014-07-15 and 2014-07-22 meetings. 22:07:16 next announcement... 22:07:35 There is a poll for selecting a mid-cycle meetup date: 22:07:36 http://lists.openstack.org/pipermail/openstack-dev/2014-July/039119.html 22:08:06 #link http://lists.openstack.org/pipermail/openstack-dev/2014-July/039119.html Poll for Mid-Cycle Meetup Date 22:08:41 please take a moment to consult your calendars and vote now 22:10:13 were you intending to have a result by the EOM? 22:10:50 we can hold the poll open until we have judged that there is a critical mass around a particular date 22:13:28 ok, next on the agenda… 22:13:31 #topic Review Action Items 22:13:41 Does it have to be SF? We're having a containers meeting at the kernel summit in Chicago; you'd be welcome to join 22:13:57 oh! 22:14:04 no, we are not locked to SF 22:14:28 jejb: when does that happen, exactly? 22:14:54 August 18 - 20, 2014 22:15:04 adrian_otto to send a poll to openstack-dev ML to select a date for the Mid-Cycle meetup (http://eavesdrop.openstack.org/meetings/containers/2014/containers.2014-06-24-16.02.log.html#l-76, 16:16:55) (COMPLETE) 22:15:12 http://lists.openstack.org/pipermail/openstack-dev/2014-July/039119.html 22:15:14 adrian_otto, KS is 18-20/8 and LinuxCon is 20-22/8 We may do 20/8 as easiest, but may also steal linuxcon dates 22:15:49 oh, very interesting 22:16:03 LinuxCon is doing a Containers track so I think there's strong Docker representation as well as LXC 22:16:52 ok, so at KS, you mentioned a containers meeting, when is that? 22:17:32 We'll do it on the fringes, it will probably be a review with Tejun of our API progress. We don't have dates nailed down but I suspect 20/8 since Serge is going to LinuxCon but not KS 22:17:57 jejb: +1; doing this with ks/linuxcon will make those that sign my expense reports happy, I think. 22:18:13 ok, so maybe if we planned to meet on the 18th and 19th that might work nicely 22:18:20 I'll have a couple of guys from Moscow, although not dguryanov 22:18:29 no chance of getting anyone to SF in August 22:19:01 and then we can meet with kernel stakeholders on the 20th 22:19:16 am I making any sense? 22:20:06 I was more thinking that the containers presence is useful. I doubt Tejun or some of the others has much OpenStack interest 22:20:18 I'd need to find a suitable meeting space for us thogh 22:20:23 but it's an attractor for the rest of the containers people, which is partly why LinuxCon has a container track 22:20:41 adrian_otto, I can get Angela of the LF to find that 22:21:09 ok, that would be great. We'll keep all options open 22:22:01 jejb: we’ll also need to know if all attendees will also need to register for linuxcon 22:22:23 erw_: yes, good point 22:22:41 erw_, that's complex. but only if you want a date over linuxcon, which is 20-22/8 22:23:05 I'm happy to provide the LF with rationale that explains why this is in the interest of the LF if that's not immediately apparent 22:24:13 thanks for making that connection for us. 22:24:39 I will update the description of the poll to indicate if we hold it on those dates, it will be in Chicago (pending final arrangements) 22:24:53 #topic Host Agent Discussion 22:25:09 adrian_otto: fwiw, “networking only” passes without conference session badges are $300/ea; if it turns out it’s necessary 22:25:43 erw_: tx! 22:26:12 recarding host agents… we touched on this a bit last week, but I wanted to give us a chance to revisit this in greater detail 22:26:24 s/recarding/regarding/ 22:27:02 the question is about what software should run on the hosts that run nova-compute today 22:27:26 should it be different than nova-compute, nova-compute with a generic containers plugin? 22:28:11 I think we agreed that we preferred not to have separate virt drivers to every container tech 22:28:39 thoughts on this? 22:29:09 I’m a bit worried about removing funtionality for specific container tech to make it fit a lowest common denominator driver 22:29:09 ok, we can follow that one on the ML 22:29:13 The problem is that the nova API is a bit hypervisor centric. However, we need a lot of the internals 22:29:17 adrian_otto: so far, I’ve agreed we need to share code amongst the “virt” drivers. Such as the neutron code and whatever code we use for attaching block devices for cinder 22:29:42 I'd propose trying a different nova-compute as a POC then seeing if there's scope for merging 22:30:05 erw_: acknowledged. 22:30:24 adrian_otto: the idea of “separate” virt drivers is a high-level subclassing where we need to do different things for the different drivers… and I don’t see that going away unless we were to, say, communicate to libcontainer directly. 22:30:25 jejb: so maybe a fork of nova-compute to start? 22:30:45 adrian_otto, it will be easier than trying to modify the python API within nova initially 22:30:54 +1 erw_ 22:30:58 erw_: we talked about extending libvirt to potentially be that integration point. 22:31:51 PaulCzar_: +1 22:31:57 libvirt is really very hypervisor specific as well 22:32:17 PaulCzar_, the libcontainer/libct approach should support all container technology with no current loss of functionality 22:32:18 take nova-docker … genericize it a bit and call it nova-container 22:32:20 and even the canonical folks want to get away from libvirt for containers 22:32:24 jejb: what if it were not? 22:32:47 adrian_otto, well then it would be reinventing the libct approach, wouldn't it? 22:32:50 erw_: where was that opinion expressed? 22:32:55 let docker be the driver to integrate with libcontainer 22:33:05 Is there an API for containers documented at this point? 22:33:12 I'd like to identify a concrete reference to that 22:33:40 iqbalmohomed: https://github.com/xemul/libct/blob/master/Documentation/libct.txt 22:33:52 PaulCzar_: iqbalmohomed: there is an argument that docker is that api 22:33:54 adrian_otto, serge can probably confirm it. It was his statement at OpenStack Atlanta, but I don't know if it's written down 22:34:02 thx dguryanov, erw_ 22:34:11 yes, we raised libct for discussion last week as well 22:34:33 libct/libcontainer is the defacto low-level api, yes 22:35:09 oh yes, I forgot about libct … it’s a python library that will talk to libcontainer ? or a python port of libcontainer? 22:35:32 but interfacing directly to that, we would start to reimplement Docker inside of our virt plugin… and that’s not good mojo 22:35:38 libcontainer is a go library, libct is the c/c++/python part. The APIs don't quite match yet but vmarmol from google is working on that 22:35:40 jejb: yes, could you help me confirm that? 22:35:44 +1 erw_ 22:35:56 adrian_otto, I can confirm he said it to the group of us 22:36:03 (or reimplementing openvz, for that matter… from whatever perspective you desire) 22:36:14 I want all of us to be well informed about what's happening, but I don't want rumor to carry us away if it's not an official position, we should treat it as such. 22:36:48 adrian_otto: it has been clearly stated by various parties that the intentions are to merge libcontainer and libct. 22:37:00 maybe we can invite serge to our next meeting for his perspective 22:37:18 erw_: ok 22:37:32 that makes sense. 22:37:34 I’m all for using docker as the API … but I’m not sure the openstack community in general would like that 22:37:45 PaulCzar_: why? 22:37:56 fi docker allows for any container tech to work 22:38:16 adrian_otto: politics, language bias, not-invented-here 22:38:18 Which container techs do we have? 22:38:21 and all those bits are open source, and using compatible licenses 22:38:22 Curious if the existing docker virt driver in nova-docker serves as a guide in the design for containers? https://wiki.openstack.org/wiki/Docker has a nice image of this ... basically use HTTP 22:38:29 There is only one: cgroups + namespaces + caps 22:38:43 Stackers have expressed interest in OpenVZ as well 22:39:05 which is something that is used in production OpenStack clouds today 22:39:52 iscsi support is one difference that I am aware of 22:40:23 I'd like to learn more about the specifics, but apparently the iscsi connector that works in OpenVZ was not working when LXC was considered 22:40:29 adrian_otto: there is a good point that Docker does present a fairly biased version of containers. 22:40:30 The flavour of a container, LXC, OpenVZ, Docker is determined by how you set it up, what capabilities you give it and how its mount points work 22:40:38 which may or may not be a good thing in the context of OpenStack 22:40:54 libcontainer/libct interfaces to the low level building blocks, but the high level flavour isn't determined by them 22:41:03 dguryanov: I believe other popular containers are warden and straight up LXC 22:41:05 erw_: in my view being somewhat opinionated is healthy 22:41:47 warden is it's own thing? I thought that simply controlled LXC 22:42:18 my approach with the docker driver has been to try and improve libcontainer directly wherever possible, to move code into libraries we can share with other container virt drivers - where possible... 22:42:29 My current understanding is that's downstream from the CF DEA component in order to produce an isolated process on the host 22:42:39 but instead of calling to libcontainer directly, we call the docker API which manipulates libcontainer. 22:43:00 as a matter of status-quo on the nova-docker side 22:43:40 erw_: for sake of discussion, if we had nova-compute talking directly to libcontainer, and added extensions for the missing API bits, might we get more traction with Stackers? 22:43:46 at dockercon they announced that paralels was working on libcontainer support 22:43:51 adrian_otto, warden was initially implemented on lxc (like docker), then it decided it wanted to do its own thing, so it has backends, like docker 22:44:05 jejb: very interesting. 22:44:57 adrian_otto: I’m not sure that would give us further traction. It moves the story to something most people don’t know (they know lxc, openvz, docker) and I suspect presumes a much more vigorous level of effort to implement and maintain 22:45:27 PaulCzar_, it's a bit more complex than that: libcontainer and libct have existed as separate projects for a while. We're now trying to combine them into a single useful API 22:45:37 PaulCzar_, with a Go/C/C++/Python binding set 22:45:44 #link http://underlap.blogspot.co.uk/2014/06/warden-meets-libcontainer.html Warden to use libcontainer now 22:46:11 it seems to me that there is convergence on libcontainer, and that would be a safe approach as a first iteration. 22:46:49 erw_: more effort compared to what option? 22:47:51 if we were to use docker as the API and we need features from libcontainer to support openvz etc, will we get support from docker to implement ? 22:48:28 adrian_otto: it’s a question of how much does libcontainer not do - and how much do we lose by using it? I mean, do we start reimplementing Docker, Warden, etc at some point? 22:49:02 erw_: I'd rather not, in all honesty. 22:49:08 and then there is the ecosystem question: if we did that, how do we manage importing/exporting docker images? Are there features we lose/miss out on? 22:49:15 It's basically a question of where the container flavour is implemented. If we base on libct/libcontainer, the flavour has to be in nova, hence extra work 22:49:18 but I want to help us strike a balance that we can be comfortable with 22:49:32 given we have something working that uses docker, I think it makes a lot of sense to continue to use it until we hit something that means we can't 22:49:40 if we place the flavour inside the actual driver (like is currently done now with libvirt), then we effectively need drivers for every container technology 22:50:32 The thing we don't yet know is how big the flavour difference is. I suspect it's pretty small, hence nova + flavour driving libct/libcontainer may not be much extra effort 22:50:51 jejb: good point. it would be more efficient to pick up those modules from existing projects 22:50:51 PaulCzar_: libcontainer is getting support from multiple vendors. parallels is working on libcontainer themselves, in a sense (again the whole c/go mismatch is being sorted) 22:51:21 but we have yet to try it. We're looking to rebase the vzctl (openvz toolkit) and serge is looking at the same for lxctools. How easy that is tells us how big the flavour problem is 22:52:06 ok, so we have a few minutes remaining 22:52:17 jejb: right. I’ve been playing devil’s advocate a bit, not because I’m strictly against a libcontainer solution, but because I feel we don’t have enough information to make an informed decision on this. 22:52:19 #topic Open Discussion 22:52:52 it's fine to continue the prior dicsussion 22:53:21 erw_ what actions can we take to get the right information? 22:53:30 thx guys, I gotta head out 22:53:30 adrian_otto: I forget where we left off with the cinder stuff, but the patches from funzo and slower are ready and pending review… which is still having trouble with upstream docker. 22:53:39 is this a matter of pulling in subject matter experts who are not already here? 22:54:09 erw_: are there individuals I should speak with about those? 22:54:12 erw_, all I can tell you is what I suspect ... not what I know. What I do know is that the future of containers is more granular than any of our current container technology easily allows so a libct/libcontainer route would future proof us, which I think is more important in the long run 22:54:47 adrian_otto: re:cinder- I had them give a demo at Docker, Inc to grease the wheels a bit. Unfortunately, most everyone had already checked-out due to an hour-log HR presentation that preceded it 22:55:12 oh, bummer! 22:55:12 adrian_otto: re:cinder- but I’m following up on it 22:55:34 erw_: If I can do anything to help, please let me know 22:56:35 jejb: that much, I can agree on. What I’ve been doing is using the openstack work as a feedback loop to make Docker better where it’s lacking and speeding up that process 22:58:14 In the closing minutes, maybe I can ask a some what related but off topic question. Is there a regular chat or irc for nova-docker? 22:58:27 sorry- - I have to go. 22:58:34 #nova-docker on Freenode 22:58:44 thx adrian_otto 22:59:01 ok, anything else before we wrap up? 22:59:34 thanks everyone. 22:59:39 #endmeeting