16:02:12 <adrian_otto> #startmeeting containers
16:02:13 <openstack> Log:            http://eavesdrop.openstack.org/meetings/marconi/2014/marconi.2014-06-24-15.00.log.html
16:02:14 <openstack> Meeting started Tue Jun 24 16:02:12 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:02:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:02:17 <openstack> The meeting name has been set to 'containers'
16:02:18 <apmelton> o.
16:02:19 <apmelton> o/
16:02:30 <thomasem> o/
16:02:31 <adrian_otto> #link https://wiki.openstack.org/wiki/Meetings/Containers Our Agenda
16:02:33 <funzo> o/
16:02:38 <s1rp_> o/
16:02:39 <adrian_otto> #topic Roll Call
16:02:41 <adrian_otto> Adrian Otto
16:02:55 <thomasem> Thomas Maddox
16:03:00 <apmelton> Andrew Melton
16:03:05 <funzo> Chris Alfonso
16:03:56 <adrian_otto> welcome everyone
16:04:32 <adrian_otto> #topic Announcements
16:04:44 <adrian_otto> Any announcements from team members?
16:05:07 <funzo> not from me
16:05:36 <funzo> unless you want to go over anything from the nova-docker subteam
16:05:36 <adrian_otto> #topic Review Action Items
16:05:41 <adrian_otto> (none)
16:05:58 <adrian_otto> funzo: please update us on activity within the nova-docker subteam
16:06:10 <adrian_otto> #topic Subteam Updates
16:06:22 <funzo> ok, cool. we have volume-attaching/detaching working
16:06:37 <funzo> the pull request to add the docker API to support runtime updates is pretty controversial atm
16:06:39 <adrian_otto> !! sweet !!
16:06:40 <openstack> adrian_otto: Error: "!" is not a valid command.
16:06:50 <adrian_otto> thanks openstack
16:06:59 <funzo> they don't really want dynamic updates to happen, which is necessary for nova volume-attach to work
16:07:25 <funzo> so, I have an email out to solomon about reviewing the PR and trying to get the API in
16:07:30 <adrian_otto> can you explain what you mean when you refer to a dynamic update, and who "they" is?
16:07:37 <funzo> it's sorta critial to enable openstack management of running instances
16:07:55 <funzo> well they in particular started with one of the maintainers of docker
16:08:34 <funzo> so i'm attempting to open a dialog so that we can get the API in soon
16:09:00 <funzo> also snapshots are working
16:09:04 <adrian_otto> API extensions for Nova, or for Docker?
16:09:05 <julienvey> oops, late!
16:09:12 <funzo> API extensions for docker
16:09:13 <adrian_otto> hi julienvey. Welcome.
16:09:30 <funzo> nova volume-attach expects to be able to attach a device to an instance
16:09:51 <funzo> docker needs to then have an API to attach the storage device to the running container
16:10:07 <adrian_otto> ok, got it.
16:10:08 <funzo> which we have commits to enable, but they aren't being accepted upstream atm
16:10:16 <funzo> so that's my update
16:10:22 <adrian_otto> I expect resistance about that
16:10:41 <funzo> heh, I didn't.
16:10:41 <adrian_otto> there is a strong preference within the docker maintainers group to keep the api unchanged
16:11:15 <adrian_otto> so to the extent that the additions don't change existing behavior, there is a chance of acceptance
16:11:25 <funzo> the pause/upause work we focused on a couple weeks ago was an API addition
16:11:30 <funzo> that was accepted upstream
16:11:35 <adrian_otto> but if it requires changing something that already exists, then expect friction
16:11:46 <funzo> it's a net new API
16:12:01 <adrian_otto> ok.
16:12:02 <funzo> v/containers/{0}/devadd
16:12:06 <funzo> v/containers/{0}/devrm
16:12:14 <funzo> so...anyway, just wanted to keep you posted
16:12:36 <adrian_otto> there is also a philosophical concern with containers being immutable
16:12:42 <funzo> that's really the rub
16:12:52 <adrian_otto> if they are ummutable, then they are truly portable
16:13:12 <adrian_otto> and if you allow them to mutate, then portability is reduced
16:13:53 <adrian_otto> ok, so I think I understand the root of that discussion
16:13:58 <funzo> they are allowing a docker run --device to attach a device at creation time
16:14:03 <adrian_otto> thanks funzo
16:14:05 <funzo> that to me, is just as non-portable
16:14:33 <adrian_otto> funzo: have you already proposed that argument?
16:14:57 <funzo> no, I haven't based my argument on that yet - just explaining the use case for openstack atm
16:15:13 <funzo> the comparative against --device is my ace in the hole
16:15:27 <funzo> except --device isn't merged yet lol
16:15:27 <adrian_otto> ok
16:15:32 <funzo> so waiting for them to merge it
16:15:33 <adrian_otto> other updates?
16:16:19 <adrian_otto> #topic Mid-Cycle Meetup for Containers
16:16:31 <adrian_otto> I should have taken an action item on this last week
16:16:55 <adrian_otto> #action adrian_otto to send a poll to openstack-dev ML to select a date for the Mid-Cycle meetup
16:16:58 <PaulCzar> sorry I’m late!
16:17:06 <adrian_otto> PaulCzar: welcome
16:17:35 <adrian_otto> sorry I have not circulated the poll yet. I have been out on ETO, and just arrived in Texas yesterday afternoon
16:17:57 <adrian_otto> last week we discussed some date constraints
16:18:12 <adrian_otto> sis anyone have any new input on selection of the meetup dates?
16:18:23 <adrian_otto> s/sis/did/
16:18:46 <adrian_otto> also, I'm looking for nominations for individuals who should be considered must-attend
16:18:47 <apmelton> adrian_otto: where were we planning to hold the meet up again?
16:18:54 <adrian_otto> it would be great to have consensus about that
16:19:01 <adrian_otto> apmelton: Y!
16:19:15 <adrian_otto> in California
16:19:31 <adrian_otto> but if there is another location that makes more sense, I'm willing to consider all options
16:20:07 <apmelton> was just wondering where, no other options from me
16:20:14 <adrian_otto> apmelton: what's your preference for location?
16:20:36 <adrian_otto> I'd like to make it easy for key stakeholders to attend
16:20:48 <adrian_otto> I know we have a few int he SF bay area
16:21:00 <apmelton> no real preference, a red-eye every now and then isn't bad :)
16:21:13 <adrian_otto> where would you fly from?
16:21:14 <funzo> adrian_otto: I'm not too far from there, so it's a short flight - I just need to have the budget discussion
16:21:21 <apmelton> I'll be flying from Virginia
16:21:31 <adrian_otto> aah, yeah, that's a long way.
16:22:01 <adrian_otto> ok, so we'll carry this on on the ML. Let me know by PM if there are particular individuals you want me to consider as must-attend
16:22:41 <adrian_otto> #topic Host Agent Discussion
16:22:59 <adrian_otto> we did not get much time last week to cover this topic in meaningful detail
16:23:11 <apmelton> so, how is host agent any different than just running compute on the host?
16:23:20 <adrian_otto> this concept surfaced during prior discussions
16:23:49 <adrian_otto> apmelton: good question. openstack-nova is a host agent already
16:24:26 <adrian_otto> so the first question we might ask is if we should use that for containers as well as VM's, or do we need yet another host agent focused on containers
16:25:20 <adrian_otto> we should consider that a variety of container technologies should fit into this host agent solution.
16:26:13 <adrian_otto> so that if someone prefers to use OpenVZ rather than LXC/Docker that we have a consistent user experience where the technologies have functional equivalencies.
16:26:28 <apmelton> if we go the separate host agent route, it would be nice if it works for all techs
16:26:41 <apmelton> without needing a bunch of different drivers
16:26:48 <adrian_otto> yes, nobody has argued to the contrary
16:27:23 <adrian_otto> if we use virt dirvers to accomplish it, then there is a lot of fooling around with arranging/loading/configuring various virt drivers
16:27:39 <PaulCzar> as long as we don’t have to support them all to the lowest common denominator ( as in drop features from docker so we have exactly same experience with openvz )
16:27:52 <adrian_otto> in the past, it was argued that perhaps libvirt might be a level playing field for this…
16:28:05 <adrian_otto> but that the libvirt API was conceptually VM centric
16:28:41 <adrian_otto> and would not support the complimentary features offered by containers. One example is the setting of shell environment variables to be present at the time the container is started
16:28:42 <PaulCzar> isn’t libcontainer the thing that docker is trying to get people to adopt as a common language for talking to container techs ?
16:29:01 <adrian_otto> PaulCzar: Yes, that's my understanding.
16:29:37 <apmelton> s1rp_: when we talked with danpb in atlanta, do you remember how he felt about more container/process stuff in libvirt
16:29:48 <PaulCzar> so in theory we could use dockerclient as our hostagent … and allow other container techs to plug in via libcontainer
16:30:21 <adrian_otto> libswarm might also fit there.
16:30:55 <julienvey> libswarm is about orchestration right ?
16:31:18 <adrian_otto> julienvey: partly. Let me try to characterize it
16:31:20 <PaulCzar> libswarm would give us scheduling in some form
16:31:35 <adrian_otto> it's a piece of middleware that fits between the docker client and the API that runs on a particular host
16:31:58 <adrian_otto> and it gives you a combined view of containers that have been started on numerous backend hosts
16:32:18 <PaulCzar> interesting thing about using libswarm is that people would then be free to choose their own host tooling …   CoreOS+Fleet or Mesos
16:32:30 <adrian_otto> each backend runs the docker API, and SSH tunnels are used to control those from wherever the Swarmd server runs
16:32:44 <julienvey> ok, thank you adrian_otto
16:32:44 <PaulCzar> so it might look similar to the vmware driver where it’s an aggregation of other hosts
16:32:49 <s1rp_> apmelton: i think danpb was amendable to the changes we were suggesting like passing in environment variables, etc...
16:33:43 <marcoemorais> PaulCzar: going back to libcontainer, how is that different from libct https://github.com/xemul/libct
16:33:45 <adrian_otto> s1rp_: as Nova extensions?
16:34:10 <apmelton> adrian_otto: nova extensions and the required libvirt changes
16:34:32 <adrian_otto> apmelton: oh, interesting!
16:34:52 <s1rp_> adrian_otto: yeah i don't know if he expessed an opinion on the nova piece, but he seemed okay with making libvirt handle more process-like use-cases
16:35:15 <PaulCzar> marcoemorais: libcontainer is Golang and docker uses it to talk to linux kernel to set up cgroups/namespaces with the idea that you could write support for say FreeBSD jails into libcotainer … and then docker would deploy those instead of linux ones
16:35:56 <adrian_otto> ok, so if we view libvirt as something we can adapt for containers use cases, then it might be a suitable choice for the host agent
16:36:21 <adrian_otto> then we would just need to decide what should drive that...
16:36:28 <adrian_otto> nova-compute
16:36:37 <adrian_otto> or perhaps something else
16:38:06 <adrian_otto> seems to me that we could afford to make an etherpad for this one, and collect ideas like we did for the previous discussion about cinder support
16:38:17 <adrian_otto> do you want to do that now?
16:38:34 <apmelton> we can definitely get started
16:38:43 <adrian_otto> ok, stand by one moment
16:39:55 <adrian_otto> https://etherpad.openstack.org/p/containers-plugin-arch
16:42:25 <adrian_otto> ok, looking good so far
16:43:59 <apmelton> I need some clarification on this
16:44:18 <apmelton> would the user of (libvirt/libcontainer/libswarm) replace nova-docker?
16:44:24 <apmelton> and nova-libvirt-lxc
16:45:10 <apmelton> and they'd basically become a single driver with different virt_types supplied to libvirt/libcontier/libswarm
16:45:22 <marcoemorais> apmelton: how is http://libvirt.org/drvlxc.html a large paradigm shift for nova-compute -> libvirt ?
16:46:13 <adrian_otto> apmelton: ideally we could shrink nova-docker down, yes
16:46:16 <apmelton> the idea of interacting with processes inside of a container is a paradigm shift for the libvirt library itself
16:46:30 <adrian_otto> that way the Nova team is in less of a position to pick favorites with respect to container tech
16:46:45 <apmelton> maybe not a large paradigm shift, but still it's definitely not something you do with VMs
16:46:47 <adrian_otto> and we just let users and operators decide what they want to use/support
16:47:28 <adrian_otto> most of the container types will have a large area of overlap for their APIs
16:51:29 <adrian_otto> ok, I think that's a good start
16:51:53 <adrian_otto> feel free to continue in the etherpad as we think about new options, and begin to get clarity on the ones we identified
16:52:00 <adrian_otto> #topic Open Discussion
16:54:45 <adrian_otto> ok, any other topics to cover today?
16:55:16 <adrian_otto> Our next meeting will be 2200 UTC on 2014-07-01
16:55:48 <apmelton> I will be on ETO next week
16:56:03 <adrian_otto> apmelton: enjoy your time away!
16:56:13 <apmelton> thanks adrian_otto!
16:56:28 <adrian_otto> anyone else lurking who would like to be recorded in attendance today?
16:56:36 <Slower> me
16:56:44 <Slower> :)
16:56:49 <adrian_otto> thanks Slower
16:57:13 <adrian_otto> ok, we'll end now. Thanks everyone for attending today. I thought this was a really valuable discussion.
16:57:17 <adrian_otto> #endmeeting