16:02:53 <adrian_otto> #startmeeting containers
16:02:53 <openstack> Meeting started Tue Sep 30 16:02:53 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:54 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:02:57 <openstack> The meeting name has been set to 'containers'
16:03:01 <adrian_otto> #link https://wiki.openstack.org/wiki/Meetings/Containers Our Agenda
16:03:06 <adrian_otto> #topic Roll Call
16:03:09 <adrian_otto> Adrian Otto
16:03:09 <Slower> o/
16:03:12 <Slower> Ian Main
16:03:17 <dguryanov> Dmitry Guryanov
16:03:18 <mspreitz> o/
16:03:20 <diga_> diga
16:03:24 <nshaikh> o/ Navid
16:03:44 <mtesauro> o/
16:03:58 <adrian_otto> I am going to add one item to the agenda before we begin
16:05:50 <adrian_otto> #link https://wiki.openstack.org/wiki/Meetings/Containers#Agenda_for_2014-09-30_1600_UTC Our Updated Agenda
16:06:12 <nshaikh> okay
16:06:34 <adrian_otto> ok, welcome everyone
16:06:50 <adrian_otto> #topic Announcements
16:07:01 <adrian_otto> any announcements from attendees?
16:07:22 <adrian_otto> #topic Review Action Items
16:07:23 <adrian_otto> adrian_otto to coordinate a follow-up about Gantt, to help the containers team understand its readiness plans, and how they may be applied in our work.
16:07:50 <adrian_otto> Status: In Progress. ISC meeting planned for this week to discuss further. Time TBD
16:08:08 <diga_> ok
16:08:12 <iqbalmohomed> is the discussion open?
16:08:14 <iqbalmohomed> on irc?
16:08:21 <mspreitz> ISC?
16:08:32 <adrian_otto> yes, we will discuss in the #openstack-containers channel
16:08:38 <adrian_otto> IRC
16:08:50 <iqbalmohomed> ok .. great .. I'll keep an eye on the mailing list
16:09:54 <adrian_otto> update: Meeting time is set for 1600 UTC tomorrow in #openstack-containers
16:10:15 <nshaikh> okay
16:10:20 <adrian_otto> channel is logged, so transcripts will be available if you are interested but can not attend, or will be otherwise offline
16:10:37 <adrian_otto> on, next topic
16:10:40 <adrian_otto> #topic Containers Service (Magnum) API
16:11:00 <adrian_otto> diga_ has been working on some initial API code
16:11:07 <adrian_otto> and I have started to informally review it
16:11:08 <adrian_otto> https://github.com/digambar15/magnum
16:11:16 <diga_> yep
16:11:35 <adrian_otto> I hope to get this into a dedicated project repo with Gerrit soon to aid in the review discussions
16:11:54 <diga_> I'll try to complete db implementation part by end of this we
16:11:56 <diga_> week
16:11:57 <adrian_otto> I will take that as a formal AI
16:12:08 <nshaikh> diga_, how are we tracking the features?
16:12:17 <adrian_otto> #action adrian_otto to follow up about the Magnum project repo, and revise the config review as needed
16:12:48 <adrian_otto> nshaikh: We should probably use an LP project for that, using blueprints
16:12:53 <mspreitz> Have I missed something, or is there no actual model for containers there yet?
16:13:03 <diga_> currently I am writting POST, GET, DELTE apis for containers
16:13:04 <adrian_otto> Slower:  you expressed an interest in working on the API code
16:13:17 <adrian_otto> did you get a chance to connect with diga on that?
16:13:31 <nshaikh> diga_, okay
16:13:38 <diga_> yes
16:13:43 <diga_> nshaikh
16:14:08 <adrian_otto> mspreitz: we are in an active design phase. The first step is to mock up the API using some disposable code, and iterate ont aht a bit
16:14:16 <diga_> Slower, you can contact me on IRC, let discuss things there
16:14:25 <adrian_otto> so once we feel comfortable with it, we can flesh that out
16:14:34 <mspreitz> no criticism, just wanted to be sure I did not miss something
16:14:59 <adrian_otto> we do have the spec proposal
16:15:03 <diga_> yes, adrian
16:15:06 <mspreitz> Is there an intention to include something like the pod concept from Google?
16:15:10 <adrian_otto> mspreitz: have you seen that?
16:15:19 <mspreitz> I guess not
16:15:32 <adrian_otto> I will get a link to that, one moment.
16:16:54 <adrian_otto> #link https://review.openstack.org/114044 Spec Proposal
16:17:35 <adrian_otto> mspreitz: the concept of pods is something that could be implemented in a higher order service.
16:17:49 <adrian_otto> if it makes sense to build it into Magnum, I think that's something we are willing to discuss.
16:17:53 <mspreitz> thanks for the pointer.  Will study.
16:18:30 <mspreitz> I think the pod concept gives you something critical: a way to wrap up into a self-contained bundle all the host-specific stuff that Docker API exposes.
16:18:43 <adrian_otto> ok, so everyone please look through the code that diga posted at https://github.com/digambar15/magnum and start to get our feedback in a discussion in #openstack-containers
16:19:48 <diga_> yes
16:20:18 <nshaikh> diga_, adrian_otto : Are we looking at consuming docker-py <https://github.com/docker/docker-py> or docker binary?
16:20:23 <iqbalmohomed> will do
16:20:33 <adrian_otto> mspreitz: agreed. What we have not yet talked about is how much to build into OpenStack, and how much we will rely on consumers of the API to implement aditional features
16:20:56 <adrian_otto> I think we'll want to set some guidelines around that.
16:21:10 <mspreitz> my point is that a cloud API should not have users talking about host specific names and numbers
16:21:47 <adrian_otto> one approach would be to try and keep Magnum as lean as reasonably possible, and provide an extension mechanism, as we do with our other services, and allow some experimental innovation to happen in community projects
16:22:40 <mspreitz> IMO, a reasonable cloud API would not expose host ports, host filesystem paths, etc
16:22:48 <adrian_otto> mspreitz: the API that produces instances does need to allow that, but a higher level API that takes container images, may not need to offer that.
16:23:11 <adrian_otto> we don't yet have a pluggable scheduler to leverage, hence our UTC 1600 meeting for tomorrow
16:23:27 <adrian_otto> and until we have that, we need to allow you to specify which host you want a container to start on
16:23:33 <mspreitz> If you want wiring between containers on a host, you need to either expose the host's wiring abilities or define a bundle concept
16:24:15 <adrian_otto> that's likely to be unique to the tools/libraries in use
16:24:26 <mspreitz> which "that"?
16:24:53 <adrian_otto> we are aiming to make a solution that is agnostic, so that it's not only a Docker solution, but can work for OpenVZ, LXC, or potentially other container types with different tools.
16:25:20 <mspreitz> What is the intersection of the wiring ability exposed to users?
16:25:32 <mspreitz> for the ones listed so far
16:26:01 <adrian_otto> that's largely unspecified at this point. We have a concept of a nested set of containers, where a container has a parent.
16:26:20 <adrian_otto> but in terms of expressing the linkage between them, we have not explored that yet in detail.
16:26:24 <mspreitz> And the Linux kernel allows an unprivileged container to subdivide itself?
16:26:49 <adrian_otto> mspreitz: our understanding is that functionality is coming soon.
16:27:02 <mspreitz> Oh, that's interesting.
16:27:03 <adrian_otto> we are proceeding under the assumption that it will appear soon as a kernel feature.
16:27:04 <mspreitz> How soon?
16:27:23 <adrian_otto> I suppose that depends on who wants to submit patches for it
16:27:50 <mspreitz> Is anyone outside this group working on that?
16:27:51 <adrian_otto> and how quickly they work. Eric Windisch indicated to me that he saw patches for it already.
16:28:25 <adrian_otto> that's something that Docker wants really bad, and is high on their priority list
16:28:41 <adrian_otto> but I'm not part of the kernel community, so I can't speak authoritatively about that.
16:29:16 <adrian_otto> technically speaking, there is no reason we can't have nested unprivileged containers with relatively small changes in the kernel.
16:29:26 <adrian_otto> so I'm reluctant to plan around that
16:29:37 <mspreitz> Could we make do in the interim, using privileged parents?
16:29:45 <adrian_otto> yes, of course.
16:29:48 <mspreitz> I mean, just one level of subdivision
16:29:56 <mspreitz> makes sense.  thanks.
16:30:26 <adrian_otto> ok, so next up on the agenda is a new thing...
16:30:36 <adrian_otto> #topic Kolla
16:30:50 <adrian_otto> #link https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg36059.html Kolla Announcement
16:31:20 <adrian_otto> A few people have been pinging me about this
16:31:36 <adrian_otto> trying to assort where this fits, and if it overlaps with what we do
16:32:44 <adrian_otto> my initial reaction is that our focus is different. It might make sense for us to explore opportunities for acting as an enabling technology for this project
16:33:18 <adrian_otto> any thoughts on this?
16:33:28 <mspreitz> I think separate..
16:33:34 <mspreitz> OOO is trying to bootstrap
16:33:44 <mspreitz> adding requirements for more context is not a help
16:33:54 <mspreitz> our container service fits into a bigger context
16:34:02 <mspreitz> requires a context
16:34:46 <adrian_otto> thanks mspreitz
16:35:26 <adrian_otto> any other thoughts on this topic?
16:35:36 <diga_> Our agenda is different than their, so I think we should keep working on the containers project
16:36:07 <adrian_otto> agreed
16:36:49 <adrian_otto> ok, so my main goal here was to make you all aware of this work, and to identify possible synergy.
16:37:09 <adrian_otto> we can revisit it again next week once we have all had some time to process it.
16:37:29 <adrian_otto> that brings us to my favorite part of our team meetings...
16:37:35 <adrian_otto> #topic Open Discussion
16:39:01 <adrian_otto> ok, seems like we might be ready to wrap up for today
16:39:30 <mspreitz> Is there any way to review service spec before it is in Gerrit?
16:39:36 <mspreitz> I mean, a way to share comments?
16:39:47 <mspreitz> I mean, the API not the spec
16:39:54 <adrian_otto> sure, you can discuss it with us in #openstack-containers
16:40:11 <mspreitz> thanks
16:40:54 <adrian_otto> anyone who arrived after Roll Call who would like to be recorded in attendance may chime in now
16:41:46 <adrian_otto> thanks everyone for attending. Our next meeting will be at UTC 2200 on Tuesday 2014-10-07.
16:41:53 <adrian_otto> #endmeeting