16:02:06 <adrian_otto> #startmeeting containers
16:02:07 <openstack> Meeting started Tue May 27 16:02:06 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:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:02:10 <adrian_otto> #link https://wiki.openstack.org/wiki/Meetings/Containers#Agenda_for_2014-05-27_1600_UTC Our Agenda
16:02:11 <openstack> The meeting name has been set to 'containers'
16:02:15 <zul> hi
16:02:19 <thomasem> o/ hey hey
16:02:21 <zul> sorry i missed the last meting
16:02:23 <apmelton> o/
16:02:27 <adrian_otto> #topic Roll Call
16:02:29 <paulczar> here!
16:02:32 <adrian_otto> Adrian Otto
16:02:36 <julienvey> Julien Vey
16:02:37 <muralia> murali allada
16:02:39 <zul> ChuckShort
16:02:40 <tomblank1> tom blankenship
16:02:41 <paulmo> Paul Montgomery
16:02:46 <thomasem> Thomas Maddox
16:02:47 <s1rp> Rick Harris
16:02:50 <stannie> Pierre Padrixe
16:03:32 <sriram_p> Sriram Padmanabhan
16:03:36 <apmelton> Andrew Melton
16:03:54 <adrian_otto> hello everyone
16:04:07 <danpb> Daniel Berrange
16:04:13 <serue> Serge Hallyn
16:04:45 <adrian_otto> I will pause for just one more moment for additional attendees. You are all welcome to chime in at any time to be recorded in the roll if we missed you in this section
16:05:05 <adrian_otto> #topic Announcements
16:05:28 <adrian_otto> welcome everyone to our second meeting. We anticipate different participants each week, as we have an alternating meeting schedule
16:05:52 <adrian_otto> for future reference the upcoming meeting schedule is published here: https://wiki.openstack.org/wiki/Meetings/Containers
16:06:08 <adrian_otto> for those of you who did not attend the first meeting:
16:06:09 <adrian_otto> #link http://eavesdrop.openstack.org/meetings/containers/2014/containers.2014-05-20-22.00.html Minutes/Log from first meeting
16:06:23 <adrian_otto> #topic Review Action Items
16:06:23 <adrian_otto> We did not have any action items last week, so skipping this
16:06:32 <adrian_otto> #topic Introductions (For attendees not present on 2014-05-20)
16:06:46 <adrian_otto> This is for voluntary introduction from new attendees. Welcome! Describe your interest in containers, and this team. What is your role in hone OpenStack community, and what should we remember about you?
16:07:10 <adrian_otto> if you prefer, you are welcome to record your interests in the etherpad:
16:07:17 <adrian_otto> #Link https://etherpad.openstack.org/p/containers Containers Etherpad
16:07:26 <adrian_otto> #link https://etherpad.openstack.org/p/containers Containers Etherpad
16:07:30 <adrian_otto> ok
16:07:44 <adrian_otto> anyone feel like an introduction?
16:07:49 <thomasem> Sure
16:08:26 <thomasem> Thomas Maddox, working at Rackspace. My interest at the moment is in improving container support for LibvirtLXC in Nova, but also container support overall.
16:09:41 <zul> Chuck SHort, working at Canonical, My interest is making containers a first class hypervisor in openstack, wrote the initial libvirt-lxc, and working on a out of tree native lxc driver
16:10:06 <julienvey> I'm Julien Vey, working at Numergy on Solum. Interested to have containers support in OpenStack first for Solum use-cases and after to manage applications with needs of fast spawn and bare-metal performance (no hypervisor overhead),  Isolation for micro-services without the cost of having to run a vm
16:11:06 <danpb> Daniel Berrange, Red Hat. libvirt upstream tech lead / architect. My interested in ensuring that Nova is able to provide 1st class support for both container & VM based virt, and to ensure Libvirt LXC is making the most of this
16:11:38 <paulmo> Paul Montgomery, Rackspace, also working on project Solum.  Along with Nova/container drivers, I'm particularly interested in securing containers (preventing backouts and such).
16:11:59 <paulmo> breakouts
16:12:02 <adrian_otto> Welcome Thomas, Chuck, Daniel, Julien, and Paul. I'm Adrian Otto, serving as your chair/coordinator/moderator. I am a Principal Architect at Rackspace, and PTL for Solum. I want container functionality, like what we get form nova-docker today, plus more to support CI/CD use cases for openstack end users
16:12:30 <adrian_otto> does anyone else wish to make an introduction?
16:12:37 <dguryanov|2> Dmitry Guryanov, Parallels, work on Parallels Cloud Server, OpenVZ
16:13:21 <jejb> James Bottomley, Parallels; interested mostly in Containers API unification and Kernel issues
16:13:40 <stannie> Pierre Padrixe, Numergy, also from Solum team. Interested mostly in Docker Container in Openstack
16:13:54 <adrian_otto> Welcome Pierre, James and Dmitry!
16:14:27 <adrian_otto> anyone else is welcome to chime in as we proceed.
16:14:58 <adrian_otto> so it seems that we all have a lot of shared interests. We began last week with identifying those interests, and did a thought exercise to tease some of the ideas out.
16:15:04 <adrian_otto> #topic Containers in OpenStack -- Stakeholder Interests
16:15:35 <adrian_otto> so for those of you who are attending for the first time this week, please record your input here:
16:15:36 <adrian_otto> #link https://etherpad.openstack.org/p/containers Containers Etherpad
16:15:52 <adrian_otto> we will take a moment to review that now, as there is new content to consider
16:15:54 <adrian_otto> and discuss
16:16:04 <adrian_otto> now, there are a lot of topics in there
16:16:36 <adrian_otto> my goal is not to debate each one today, but instead to give us all a high level idea of where we are all coming from, and focus us i the areas where we have the strongest sense of shared insterest
16:17:59 <adrian_otto> danpb: you may want to skim to the bottom to give the proposed use cases some consideration for our next agenda item
16:18:20 <danpb> adrian_otto: yes, i saw those, its a nice list
16:18:42 <adrian_otto> ok, great, feel free to hack that up or build on it
16:19:39 <thomasem> I'll continue to flesh out my section in the stakeholder section as I organize my thoughts better. :)
16:19:55 <adrian_otto> thomasem: good. There's no rush.
16:20:03 <thomasem> cool
16:20:05 <dguryanov|2> We're interested in containers, which are suitable for hosters, i.e. environment inside container is hostile. It's not possible on vanilla kernels, only on OpenVZ ones.
16:22:26 <adrian_otto> dguryanov|2: It would be great for you to reach out to paulmo, as you both have an interest in making container environments very secure. We all want that, I expect, but I'd like to have those who take a special interest in the security aspects to become better acquainted.
16:22:59 * paulmo nods.  Containers + a Mandatory Access Control mechanism such as SELinux may hold some possibilities
16:23:38 <adrian_otto> Once you all have had a chance to read through the etherpad, and would like to begin group discussion on next steps, please chime in here
16:23:46 <zul> so i was wondering if there is an appetite for a containers framework ala ironic, there was some discussion about this at ODS
16:24:00 <jejb> security contexts really don't help with hostile root.  The eventual solution will be USER_NS
16:24:11 <thomasem> We're also pretty interested in that as well. Already have some basic SELinux stuff up around containers. We have a few folks that aren't here today focused on container security on our team. I'll communicate to them that there is a good opportunity to collaboration here.
16:24:27 <thomasem> s/to/for/
16:24:51 <paulmo> jejb: There are many layers to this security onion for sure. :)  thomasem: Great!
16:25:12 <danpb> yeah, different people have different standards for what they'd consider "Secure" to  mean
16:25:32 <thomasem> definitely
16:25:33 <danpb> some people think that upstream kernels with userns are "secure" containers
16:25:37 <paulczar> has anyone looked at and have comments to make on the selinux support added to docker 0.11 ?
16:26:07 <jejb> danpb, pretty much, they are ... we think user_ns is more secure than the original OpenVZ root capability
16:26:45 <adrian_otto> I added a Top Theems section to the etherpad at the top
16:27:06 <adrian_otto> if I am missing any of the ones where we have strong shared interest, please feel free to add to that list
16:27:21 <danpb> the flip-side is that other people will say that allowing the host kernel to mount any untrusted filesystems is insecure no matter what you might do (given that we've seen CVEs in filesystem drivers like ext3/ext4 before)
16:27:48 <serue> very mudh so yes  (atm)
16:27:58 <serue> and, currently, not allowed :)
16:27:58 <jejb> The solution to mount is being discussed on the lxc mailing list, but I agree it's a problem
16:28:20 <serue> it seems clear to me that a fusefs with process running as container's root uid on the host is the answer
16:28:30 <jejb> This is one of the "best practise" areas where all containers do different things
16:29:22 <danpb> yep, and it's probably not for OpenStack to care about the particular underlying impl / security architecture
16:29:25 <jejb> sorry, have to run to next next meeting
16:29:36 <adrian_otto> jejb: thanks for attending
16:29:48 <danpb> but rather to just follow whatever security best practices the specific container technology recommends
16:30:02 <adrian_otto> danpb: +1
16:30:31 <adrian_otto> ok, would anyone like more time for reviewing the Etherpad?
16:30:51 <danpb> adrian_otto: i think you should continue, given we're already 1/2 way through our time
16:30:58 <adrian_otto> I'd like to suggest some action items around the Top Themes
16:31:25 <adrian_otto> my thought there is to make those into a section on the Team Wiki
16:31:36 <adrian_otto> and plan our next agenda(s) based on those
16:31:53 <zul> thats fine with me
16:32:00 <julienvey> looks good
16:32:11 <adrian_otto> I'm happy to start an ML thread as well tagged with [Containers][Nova] that solicits input too
16:32:13 <zul> i think we should start the discussion :)
16:32:26 <zul> adrian_otto:  please
16:32:51 <adrian_otto> #action adrain_otto to begin an ML thread for input on our Top Themes, and formation of a Wiki page to clearly document them for future reference
16:32:58 <funzo> hi, sorry I'm late o/
16:32:59 <adrian_otto> typo on my name
16:33:11 <adrian_otto> irc://irc.freenode.net:6667/#action adrian_otto to begin an ML thread for input on our Top Themes, and formation of a Wiki page to clearly document them for future reference
16:33:14 <danpb> not entirely sure that theme #4 is really an item on its own is it ?
16:33:16 <adrian_otto> ok, close enough
16:33:46 <danpb> i mean "can use a variety of container technology" is really just inherent in anything openstack does
16:33:48 <adrian_otto> danpb: good point, it's realyl a sub point on the #1 theme
16:34:07 <danpb> everything is always pluggable with different impls in openstack world
16:34:20 <adrian_otto> danpb: +1
16:34:22 <julienvey> it should drive our decisions, but is not a theme on its own
16:35:10 <adrian_otto> ok, I axed that one
16:35:20 <adrian_otto> let's advance to our next topic
16:35:30 <adrian_otto> #topic Containers Use Cases
16:35:37 <adrian_otto> Examine/enumerate use cases / scenarios for containers which do not require cinder storage, to demonstrate that cinder should be considered optional for Nova driver inclusion (Daniel Berrange / danpb)
16:36:08 <danpb> so i think the examples people have listed there are a pretty decent representative set
16:36:13 <adrian_otto> I copied the drafts of the use cases to discuss into the bottom of the same etherpad: https://etherpad.openstack.org/p/containers
16:36:32 <danpb> its pretty clear from them that containers are plenty useful without cinder
16:37:11 <adrian_otto> ok, thanks danpb. Are there any alternate points of view to consider on this subject?
16:37:14 <julienvey> the end goal is to have some sort of persistent storage, and if we don't use cinder, we should be sure to have a way to do this
16:37:40 <danpb> ultimately what we're showing here is that there's any number of ways to get persistent storage via the network, instead of direct attached storage
16:37:46 <adrian_otto> julienvey: Eric Windisich suggested a service like Manila may be the long term answer to that concern.
16:38:05 <julienvey> yes, Manila could be a good option
16:38:11 <adrian_otto> Trove is another
16:38:54 <dguryanov|2> Excuse me, I've missed previous meeting, what is the problem with attaching cinder volumes to containers?
16:39:33 <danpb> dguryanov|2: there's no real fundamental problem IMHO
16:39:35 <adrian_otto> dguryanov|2: good question, the practice can require an insecure instance of a container where the mount functions are available, and allow a breakout.
16:39:46 <adrian_otto> at least that was Eric's concern about Docker containers
16:39:47 <danpb> dguryanov|2: it was really just that  Docker doesn't support exposing block devs to its containers
16:39:58 <julienvey> yes, mostly a Docker problem
16:40:04 <adrian_otto> apparently there is at least oen way to mitigate that that the nova-docker team has been working on
16:40:05 <danpb> and some  Nova  cores suggested that should be a blocker that prevents acceptance of docker
16:40:26 <danpb> so this was just an attempt to demonstrate that lack of  cinder support should not be a blocker for docker acceptance
16:40:50 <adrian_otto> ok, so nobody chimed in with an alternating point of view, so can I conclude we have unanimous consent on this topic?
16:41:19 <danpb> for libvirt LXC at least, we *can* expose arbitrary host block devs to containers, and i guess openvz probably can too
16:42:08 <dguryanov|2> You can't allow both direct access to a block device and mount. But either mount or read/write has no big security problems.
16:42:19 <adrian_otto> danpb: yes, my understanding is it can be done, as long as it's done at container creation time. I am uncertain if it can be done at an arbitrary future point in time without a clever approach.
16:42:32 <thomasem> Yeah, you can mount from the host
16:42:46 <adrian_otto> like using a bind mount, and placing device files on that as needed
16:42:48 <thomasem> That's what we already do with the container image anyway
16:42:52 <thomasem> yeah
16:43:27 <dguryanov|2> Bind mounts is another question, I was talking about providing access rights to a real block device.
16:43:42 <dguryanov|2> I think nova API should be extended for bindmounts :)
16:43:58 <dguryanov|2> And instead of providing block device name, you should provide mount point.
16:44:12 <adrian_otto> ok, I am going to open us up for Open Discussion
16:44:16 <danpb> dguryanov|2: yep, its quite possible we should do that
16:44:23 <adrian_otto> #topic Open Discussion
16:44:25 <danpb> dguryanov|2: that could be useful with full machine virt too
16:44:41 <danpb> dguryanov|2: because in combination with a guest agent, it'd let you expose the block dev & mount it in the guest in one go
16:45:25 <dguryanov|2> Yes, agree
16:46:27 * danpb has to leave now unfortunately
16:46:35 <thomasem> catch ya later
16:46:42 <adrian_otto> danpb: thanks very much for attending. Catch you next time.
16:47:20 <adrian_otto> does anyone have suggestions for our top topics for next week?
16:48:18 <thomasem> It'd be good to catch up and the perception of our discussion around cinder, it sounds like.
16:48:32 <thomasem> s/and/on
16:48:52 <julienvey> we could start discussing Theme 2 "Drive agreement on where containers belong"
16:49:00 <adrian_otto> thomasem: I can attend the next Nova team meeting and report our consensus on that topic, and invite anyone with opposing viewpoints to join us for a discussion on that topic.
16:49:13 <thomasem> adrian_otto: sounds good to me!
16:49:30 <adrian_otto> we have been asked to act as a Nova sub-team concurrently
16:49:48 <thomasem> Ah, I see
16:49:57 <adrian_otto> #action adrian_otto to attend upcoming Nova meeting, and report Containers Team position on cinder support for containers in Nova
16:50:23 <dguryanov|2> I think we should discuss implementation details, it seems we all want to add our technology to openstack, but nova guys will never accept 4 different drivers.
16:50:24 <adrian_otto> last week ewindisch attended and checked in for us
16:51:17 <adrian_otto> dguryanov|2: good idea. Were you thinking of this in the context of the suggestion above from julienvey, or as a separate topic?
16:51:19 <hazmat> wrt to docker .. there's another category of issues, runtime attachment of resources and the application container.. isn't really supported. ie. attach neutron port
16:51:45 <thomasem> Yeah, that's one I haven't tested with libvirt-lxc too
16:51:55 <adrian_otto> hazmat: indeed. The idea of a host agent was raised as an option to address that
16:52:02 <adrian_otto> we should debate the merits of that option
16:52:28 <thomasem> That'd be a good discussion. Hopefully by then I will have had time to see whether that is or isn't possible with existing libvirt-lxc, and perhaps ponder some solutions.
16:52:34 <thomasem> We shall see :)
16:53:28 <paulczar> the method preferred by the docker community to update mounts etc in realtime is to destroy/recreate the container
16:54:16 <dguryanov|2> adrian_otto: after we reach an agreement on that topic
16:54:17 <paulczar> I think it would be worth looking at addressing it like that … rather than trying to force it into acting like a regular openstack vm
16:54:40 <adrian_otto> dguryanov|2: ok, tx
16:55:13 <thomasem> I'd be especially interested in the limitations there. That strikes me more as a workaround, then again, the containerized way of thinking is that we have the flexibility to do things like that.
16:56:15 <thomasem> I've got to drop off. I'll catch y'all next time!
16:56:17 <adrian_otto> Ok, I have added two discussion topics for next week here: https://wiki.openstack.org/wiki/Meetings/Containers#Agenda_for_2014-06-03_2200_UTC
16:56:24 <thomasem> sounds good!
16:56:27 <adrian_otto> feel free to add to that
16:56:32 <adrian_otto> thomasem: see you next time
16:57:19 <adrian_otto> ok, any final thoughts before moving to adjournment today?
16:58:01 <adrian_otto> oh, ewindisch has appeared!
16:58:44 <ewindisch> hi
16:58:54 <ewindisch> oh, off by hour error?
16:58:57 <ewindisch> :(
16:59:00 <adrian_otto> Thanks everyone for your time and attention today. I look forward to seeing you again  on 2014-06-03 at 2200 UTC
16:59:04 <adrian_otto> #endmeeting