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