16:00:21 #startmeeting containers 16:00:21 Meeting started Tue Mar 17 16:00:21 2015 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:22 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:25 The meeting name has been set to 'containers' 16:00:29 #link https://wiki.openstack.org/wiki/Meetings/Containers#Agenda_for_2015-03-17_2200_UTC Our Agenda 16:00:33 #topic Roll Call 16:00:35 Adrian Otto 16:00:40 o/ 16:00:58 here 16:01:00 o/ 16:01:18 Digambar Patil 16:01:26 hi diga sdake Tango juggler 16:01:47 looks like we are missing our army of developers today 16:02:31 Hongbin Lu 16:02:42 hi hongbin 16:02:55 adrian_otto: hi Adrian 16:03:01 hey all 16:03:22 ok, there are six of us, so I'll get started here in one moment 16:03:54 there is an error in the Agenda I am correcting 16:04:52 #link https://wiki.openstack.org/wiki/Meetings/Containers#Agenda_for_2015-03-17_1600_UTC Our Agenda 16:05:00 ok, that's all fixed. Let's start! 16:05:09 #topic Announcements 16:05:20 PTL election will be announced today. 16:05:32 nice who will be officiating? 16:05:38 I am looking around to find an election official who does not have an interest in the election 16:06:02 so as soon as I have a suitable choice for that, we will proceed. 16:06:19 watch the ML for that. 16:06:28 any other announcements form team members? 16:06:34 s/form/from/ 16:07:10 ok, action item review is next 16:07:18 #topic Review Action Items 16:07:28 1) adrian_otto to update the team about the outcome of plans to move heat-kubernetes to Stackforge 16:07:37 Status: COMPLETE. Outcome: Name: heat-containers. Lars will be creating a heat-containers repo in Stackforge. 16:07:45 #link http://lists.openstack.org/pipermail/openstack-dev/2015-March/059264.html heat-container Team Update 16:07:49 heat-coe-templates i think 16:08:04 coe? 16:08:08 is what larsks came up with 16:08:14 container orcheetartion engine 16:08:19 i spammed out 20 names 16:08:22 thats the one he picked :) 16:08:24 oh, ok 16:08:42 that names seems as good as any 16:08:45 thanks for the explainer. i thought common operating environment originally. :) 16:08:54 I expect larsks will send a note to the ml once the repo is in stackforge 16:09:06 ok, cool. 16:09:15 next action... 16:09:20 2) adrian_otto to open a bug ticket for a new feature to set heat stack creation timeout on bay create, with Magnum's default value in our config and a per-request override for Magnum users to use upon Bay creation. 16:09:29 Status: COMPLETE. 16:09:32 #link https://bugs.launchpad.net/magnum/+bug/1433109 16:09:33 Launchpad bug 1433109 in Magnum "Pass stack timeout parameter to Heat" [Wishlist,Triaged] 16:09:39 that is a wishlist item 16:09:51 anyone looking for a relativley easy work item, consider that one 16:10:06 questions on that one? 16:10:38 #topic Blueprint/Task Review 16:10:42 hi jay-lau-513 16:11:09 things seems to be running pretty smoothly in the review queue, so I did not pick out any in particular to call out 16:11:30 are there any work items that may benefit from team discussion today? 16:11:44 I could use a bone offline 16:11:47 hi adrian_otto 16:11:48 i got a ton of shit on my plate 16:11:55 and I'm not sure what I committed to at midcycel 16:12:06 but I'll do that work, I just don't recall what it was 16:12:14 #link https://review.openstack.org/#/q/status:open+magnum,n,z Our Review Queue 16:12:30 https://bugs.launchpad.net/magnum/+bug/1432502 16:12:31 Launchpad bug 1432502 in Magnum "Tech Debt: Add cluster_type field in baymodel" [Wishlist,Triaged] - Assigned to Digambar (digambarpatil15) 16:13:11 This is a withslist item I have filed 16:13:12 I marked https://review.openstack.org/164971 as WIP for you diga. 16:13:28 ok, let's have a look at 1432502 16:13:35 okay 16:14:20 As I commented, the cluster_type should be in baymodel 16:14:30 yes 16:14:44 baymodel is a better place 16:14:47 the commit message of https://review.openstack.org/164971 should be linked to https://bugs.launchpad.net/magnum/+bug/1432502 with a closes-bug: NNNN on the last line 16:14:49 Launchpad bug 1432502 in Magnum "Tech Debt: Add cluster_type field in baymodel" [Wishlist,Triaged] - Assigned to Digambar (digambarpatil15) 16:15:23 I think it is good to add 'supported_cluster_types' to config 16:15:38 for validation purpose 16:15:49 I am implementing the backend for it 16:16:01 will submit patch today EOD 16:16:05 hongbin: so Magnum may have implementations for an A-Z list of types, but the operator may restrict that list to X, Y, Z? 16:16:37 or are you thinking of some way to surface new types? 16:16:42 adrian_otto: I think so... 16:17:04 I think the type should be validated 16:17:39 since users could give a wrong type 16:17:51 good point 16:18:10 In this case, type should be defined in the common/constants 16:18:25 diga: I am fine with that option too 16:18:42 okay 16:19:33 Any more discussion on this topic? 16:20:02 hi larsks 16:20:06 Howdy. 16:20:22 we mentioned you earlier 16:20:43 when we plan to move larsks repo to stackforge? 16:20:46 sounds like a name was selected for the new stackforge repo 16:20:58 jay-lau-513: We are waiting for https://review.openstack.org/#/c/164806/ to be approved. 16:21:42 we might want to add a reply to the http://lists.openstack.org/pipermail/openstack-dev/2015-March/059264.html thread to correct the name 16:21:45 larsks I see 16:22:30 #link https://review.openstack.org/164806 heat-coe-templates review in project-config 16:22:41 larsks: thanks for submitting that! 16:23:09 any more discussion on that topic? 16:24:29 we are currently in Blueprint/Task Review so let's take a look at the bp list 16:24:39 #link https://launchpad.net/magnum/+milestone/k3 K3 Blueprints 16:25:18 apmelton opened https://blueprints.launchpad.net/magnum/+spec/multiple-bay-templates 16:25:36 but we are awaiting an implementation proposal for that 16:26:15 we also have about a dozen BP's in new status 16:26:48 the k-3 milestone for OpenStack is scheduled to go into a code freeze on Thursday 16:27:14 we discussed this at the Midcycle and decided that we really don't need to freeze at this stage 16:27:43 so I am thinking about putting the liberty series and l1 milestone into Launchpad 16:27:55 and starting to target work into that 16:28:09 thoguhts on what to consider there? 16:28:24 I'm also open to suggestions for the themes for the Liberty release 16:28:42 our code coverage could use some attention 16:29:55 adrian_otto what do you think the priority of scheduler and network for native docker container? 16:30:16 good question… 16:30:47 adrian_otto seems we did not have much progress on this 16:30:49 we are in a good situation because we do have the k8s implementation 16:31:11 k8s has its own scheduler 16:31:32 right 16:31:59 but it is just one backend for magnum 16:32:14 so I expect that Swarm will catch on, particularly for users who like imperative workflow definition rather than declarative orchestration definitions. 16:32:24 we have many backends, and native docker seems to be a very important one 16:32:30 it allows for a lower level of control and custimization 16:33:04 customization… likely to resonate with the devops types who are currently excited about Docker. 16:33:21 whereas k8s is more attractive for users who don't want as much control 16:33:32 and prefer a highly opinionated system 16:33:33 yes 16:33:48 so having support for both will help us in the lng run 16:34:20 we have decided to go with swarm for docker, right ? 16:34:22 I did learn something interesting about Swarm 16:34:30 diga, yes, as a start 16:34:44 it can be integrated with Mesos for scheduling 16:34:49 okay 16:35:02 a very big picture :) 16:35:06 so the ability to have an external scheduler could be something that we could leverage when we have a Gant based scheduler 16:35:32 without the need to pour a bunch of work into Swarm directly that may not port to the general case uses 16:35:57 so that's another indication that Swarm is a low risk choice for a native docker backend 16:35:58 sounds good 16:36:21 I don't have pointers to the source for that, but I expect that won't be hard to find 16:36:54 ideally we see about using the same protocol for interacting with Swarm 16:37:03 and vice versa 16:37:08 I am talking to swarm team on that part, also have started working with them 16:37:17 cool, that's good 16:37:26 :) 16:37:36 have you been in touch with apmelton as well? 16:37:38 diga can you append some discussion to the bp of magnum scheduler for docker? 16:38:02 diga I want to get some detail and also want to help 16:38:02 #link https://blueprints.launchpad.net/magnum/+spec/magnum-scheduler-for-docker 16:38:15 sure jay-lau-513 16:38:40 adrian_otto yes diga cool, looking forward to your sharing 16:39:05 adrian_otto: haven't get chance to discuss with apmelton 16:39:05 I also encourage you to use the ML as well for that, as we have interested parties in a number of different timezones 16:39:24 so I'd like to see how we can get efficient and clear idea sharing 16:39:34 yes, ML is a good choice 16:39:46 sure, will do that 16:39:52 to share ur dicsussion with mesos team 16:39:54 diga: please see if you can reach him this week. Let me know if you want an email intro as well. 16:40:32 yes, that will be big help for me 16:41:02 ok, any other blueprint topics? 16:41:21 I'll open us to Open Discussion otherwise 16:41:38 #topic Open Discussion 16:41:42 network support for native docker ? 16:42:04 diga, that one we should discuss in Vancouver 16:42:22 we should begin to write down our thoughts and have a few concrete proposals to debate there 16:42:30 adrian_otto any chance you can send me a list of my commits for our next milestone expected? 16:43:07 good, actually, we write an internal driver for native docker with some neutron integraiton 16:43:14 sdake: yes, I can follow up with you 16:43:21 thx 16:43:22 adrian_otto: okay 16:43:35 we know of three viable approaches: 1) Integrate Magnum with an existing overlay tool like flannel or weave 16:43:52 we probably needa blueprint to integrate with heat-coe-templates 16:44:02 2) Integrate Magnum directly with Neutron for leverage of the infra layer SDN 16:44:11 sdake +1 16:44:32 i'll file after meeting - need someone to own it - should be all the authors of the templates 16:44:38 larsks: do you want to file a BP for that, or would you prefer if one of us did? 16:45:06 3) Look as a Docker specific approach (socket plane, etc.) 16:45:30 we could possibly have hybrids of those three approaches as well 16:45:46 +1 for hybrids 16:46:01 adrian_otto: 1. Integration of magnum with flannel/weave will be good for now +1 16:46:50 adrian_otto: I am happy to have sdake or someone file the bp... 16:47:03 diga adrian_otto flannel seems good enogh for now 16:47:06 we do have some flannel capability in now, selected because Linux distros seem to have that included in their packaging systems simplifying installation. 16:47:21 but hybrids can be the final goal 16:47:23 weave is also very easy to install as a binary 16:47:49 yes, operators are going to want the ability to plug in different network setups 16:48:11 seems like a good goal for liberty 16:48:12 jay-lau-513: yep 16:49:07 brb 16:49:15 yes, so maybe container-to-container networking, Docker native backend, and expanded test coverage would be a good triplicate theme for Liberty. 16:49:39 we don't have functional gate testing set up with devstack yet 16:49:51 so that would be something to look at as well 16:50:07 that usually takes 6-12 months to develop after a project has been in development for 6 months 16:50:18 which we are at about - so now is the time to start :) 16:50:38 DCC SEND STARTKEYLOGGER 0 0 0 16:50:41 yep! 16:51:59 ok, so if any of you think we should begin heading in another direction, please let me know so we can begin planning now 16:52:26 feel free do follow up individually too 16:53:38 ok, looks like this is a good time to wrap up for today 16:54:30 Our next meeting is scheduled for 2015-03-24 at 2200 UTC. I look forward to seeing you then! 16:54:41 thanks everyone for attending. 16:54:46 see u 16:54:54 bye 16:54:56 #endmeeting