16:01:03 #startmeeting containers 16:01:03 Meeting started Tue Apr 14 16:01:03 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:01:04 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:01:05 #link https://wiki.openstack.org/wiki/Meetings/Containers#Agenda_for_2015-04-14_1600_UTC Our Agenda 16:01:06 The meeting name has been set to 'containers' 16:01:12 #topic Roll Call 16:01:15 Adrian Otto 16:01:42 jay-lau-513 16:01:46 Rob Pothier 16:01:48 Ton Ngo 16:02:16 Perry 16:02:19 Andrew Melton 16:02:47 hello jay-lau-513_, rpothier, Tango, juggler, and apmelton 16:03:50 o/ 16:04:03 hi hongbin 16:04:12 we will begin in just a moment 16:04:19 Janek Lehr 16:04:49 hi jjlehr 16:04:50 #topic Announcements 16:05:02 OpenStack Design Summit, Vancouver 16:05:07 o/ 16:05:33 Magnum has been allocated a number of slots for design sessions, in different formats 16:05:59 we have the "fishbowl" sessions that are set up for large audience participation (stadium seating) 16:06:17 and we have a workroom format that is a boardroom seating format 16:06:41 that is intended for smaller audiences, and for active contributors to work through current issues. 16:06:57 I will be working with you to match our topics with those session slots 16:07:23 note that the "fishbowl" sessions will appear on the ODS program schedule 16:07:28 and the others don't 16:07:33 any questions so far? 16:08:01 ok, great. 16:08:23 we are approaching the end of the Kilo cycle now 16:08:45 so we should converge on a time to cut another Kilo release 16:09:16 I'd like to do that soon. I'd like to get your input on any "must have" features that still need to land prior to cutting the release. 16:09:55 thoughts on any work-in-progress that we feel is important enough to hold up a release in order to fit it in? 16:10:24 I'd say the docker conductor actually using swarm bays is pretty important 16:10:35 +1 16:10:56 thanks apmelton. What's our outlook on the timing of code completion for that feature? 16:11:14 apmelton can you show the bp link? 16:11:24 I can add it later in the agenda if that's an involved update 16:11:27 jay-lau-513_: let me grab that 16:11:29 +1 16:11:48 https://blueprints.launchpad.net/magnum/+spec/magnum-docker-backend-selection 16:12:04 adrian_otto: yes, it'll be a more involved update 16:12:10 hi sdake and Fang_fenghua_ 16:12:23 ok, I will re-raise it in BP/Task discussion. 16:12:28 apmelton, yes, I was asking a question in ML, hope can get some comments from you 16:12:39 jay-lau-513_: I'll check it out 16:13:01 ok, that concludes prepared announcements. Any announcements from team members? 16:13:09 I have one 16:13:15 proceed hongbin 16:13:20 I am on vacation this friday 16:13:23 apmelton just search How to use docker-swarm bay in magnum 16:13:27 in two weeks 16:13:56 period :) 16:13:57 so you will be away for two weeks starting on 2015-05-17? 16:14:03 yes 16:14:08 I mean 2014-04-17 16:14:11 Is this what you are looking for apmelton? 16:14:11 https://github.com/openstack/magnum/tree/master/magnum/templates/docker-swarm 16:14:15 o/ 16:14:20 ok, thanks for the heads-up on that 16:14:36 we will do our best to help you close out any open reviews prior to 4/17 16:14:51 so team: 16:14:55 If you plan on being away 16:14:58 andrian_otto: thx 16:15:09 and you have code under review that does not merge prior to your departure... 16:15:22 please consider using the "Abandoned" state for such a review 16:15:26 sorry was late, just read through scrollback - questionabout sessions, how many do we have to feel? 16:15:32 you can being it back again when you return 16:15:52 sdake: I will revisit that in Open Dicsussion 16:16:05 hongbin is horiontal scale going to finishby friday? 16:16:07 we have 8+4 I think 16:16:36 sdake_: I will try to achieve that 16:16:43 if you don't want to use abandoned and revisit the code when you return, there is another option 16:16:45 hongbin if it does not please send me an emai 16:16:55 and i will take over the work 16:17:01 you can ask another contributor to take over the patch and continue making revisions while you are away 16:17:05 sdake_: sure 16:17:11 there we go. 16:17:42 ok, any other Announcements before we advance topics? 16:18:39 #topic Review Action Items 16:18:50 sdake_: did we have action items from last meeting to follow-up on? 16:18:56 no 16:19:06 thanks! 16:19:08 #topic Blueprint/Task Review 16:19:15 #link https://blueprints.launchpad.net/magnum/+spec/simplify-api-model Simplify API Model 16:19:19 Pardon my being late. 16:19:20 Maybe we should table this completely. Let's discuss. 16:19:23 o/ 16:19:24 welcome thomasem 16:19:30 ok, so first some background 16:19:35 Ispent about 3-4 days implementing this 16:19:41 and there are two outcomes to the implementation 16:19:56 option #! we end up with a /kobject/pod|service|rc 16:20:03 i.e. nested rest controller 16:20:05 this buys us nothing 16:20:20 option #2 we end up with one object with *all* properties in it 16:20:22 we can filter the properties in and out 16:20:28 and store in the database by object 16:20:32 but it seems untidy to me 16:20:43 that would make the source harder to follow 16:20:50 can't just look at a class to see what's in there 16:20:54 the actual rest api that is exposed by kubernetes does not use files 16:21:00 it uses a bunch of keyvalue pairs 16:21:21 take for example a get operation 16:21:30 you have to specify a type to get 16:21:37 that will call one of the 3 backend handlers 16:21:54 so we end up with if elif all over the kobject code 16:22:51 the code i wrote is really hard to follow with this model 16:22:55 it sounds like either case adds lots of complexity without buying us anything 16:23:08 the second model gets us one api to work with all kubernetes objects 16:23:12 pursuant to our IRC discussion yesterday, my preference is to KISS, and chalk this one up to lessons learned. 16:23:21 agree with adrian 16:23:21 sdake_ I think k8s itself also using a specified type to get object 16:23:31 sdake_: you indicated you are comfortable taking no further action on this BP, is that right? 16:23:50 i'm not hung up on it, maybe there is a simpler way that I just dont see 16:24:22 I really like the idea but the code in the api will be hard to follow 16:24:25 good. the reason I wanted to bring this up in our team meeting is to see if others have ideas on an approach that might be better 16:25:00 perhaps what should happen is we should remove it from essentia lblueprints 16:25:02 make it low 16:25:07 take it out ofk3 16:25:16 i'll finish the implementation and folks can ee what htey think 16:25:33 ok, and anyone who has an epiphany about this one is welcome to chime in later 16:25:37 I have big big concerns with introducing a change of this magnitude this late in the cycle 16:27:25 thanks sdake_ 16:27:29 I updated the BP accordingly 16:27:34 thx 16:27:48 next one 16:28:06 #link https://blueprints.launchpad.net/magnum/+spec/multiple-bay-templates Multiple Bay Templates (for the purpose of introducing Swarm Bay) 16:28:16 apmelton: you have the floor 16:28:32 so, there's a good amount of work left on this 16:28:56 TemplateDefinitions have laid the ground work to allow bays other than k8s 16:29:01 iirc our deadline is the 25th 16:29:19 sdake_: correct 16:29:29 will it land by then? 16:29:47 I think that may be cutting it very close 16:30:08 so we have some choices here 16:30:23 1) We can coordinate for more Stackers to help out with this BP 16:30:38 in efforts to make it advance a bit more quickly 16:31:00 2) We can delay our release until it finishes 16:31:10 3) We can re-scope it to a subsequent release 16:31:18 or combinations of these options 16:31:28 with #3 we get more capacity to work on other blueprints which may be higher priority as well ;-) 16:31:50 apmelton: is there a bite-sized chunks of work for this that someone can help with? 16:31:51 so, I do know diga was planning to help out 16:32:12 and I've got the time again to dedicate to finishing this up 16:32:15 yes, diga does intend to assist 16:32:56 ok, so it sounds like today is too early to make the call on #3 unless we have other "must have" features for the final kilo release 16:33:27 we have 2 must have features 16:33:36 Is the deadline the 25th of this month? 16:33:43 jjehr ack 16:33:45 jjlehr: yes 16:33:55 we want to merge in all Kilo features by then 16:34:18 unfinished features will be re-scoped to a liberty release 16:34:49 external-lb 16:35:04 secure-kubernetes 16:35:12 and https://blueprints.launchpad.net/magnum/+spec/python-k8sclient 16:35:35 i don't think secure-kubernetes is going to happen 16:35:36 those are our three Essential BPs in LP right now 16:35:55 it requires adding tls to the pythonk8scleint madhuri sorted out 16:36:17 Vilobh Meshram is not present today, correct? 16:36:24 i finally got documentation on *how* to setup tls 16:36:32 dims: at a high level, these are the pieces: https://gist.githubusercontent.com/ramielrowe/d1a7d15d37f65905be5e/raw/a9bb442042193c3b304a3dae1d15e1186bd7d324/gistfile1.txt 16:37:11 diga was planning to assist on 4/5 16:37:11 thanks apmelton 16:37:34 if someone would like to pick up 1/2 that would help out 16:38:14 ok, so FTR the work items apmelton is asing for assistance with are: 1) Add coe attribute to BayModel models, 2) Use coe attribute in heat handler's get_template_definition(...) calls 16:38:20 I don't expect anyone will deploy kilo of magnum because it lacks tls security 16:38:37 and functional tests 16:39:21 sdake_: at this stage, there will be lots of folks who want to start playing around with Magnum 16:39:32 play diferent then deploy 16:39:39 yes, indeed 16:40:07 i wouldn't recommend deploying magnum without tls security of kube/docker 16:40:30 ok, so any volunteers to join in with apmelton on the #1/#2 work items mentioned above? 16:41:07 so, I do actually have a question, do we plan to move to consuming stackforge/heat-coe-template for kilo? 16:41:20 production ready as a criteria would be next cycle? adrian_otto sdake_ 16:41:20 liberty 16:41:24 alright cool 16:41:27 dims ack 16:41:49 apmelton: we should probably just use a bug ticket for that 16:42:01 that's a refactor, not a new feature 16:42:22 seems more like a blueprint to me ;-) 16:42:31 sorting that out is going to be painful 16:42:35 yes it is 16:42:39 dims: production ready is a good PB topic for liberty 16:42:47 ++ 16:42:53 and if I can drop that from my todo, it'll actually free up a good amount of time I'd plan to spend on it 16:42:53 fair enough 16:43:09 spend on it for kilo* 16:43:10 tango around? 16:43:17 yes, Tango is 16:43:24 sdake_: yep 16:43:29 2 weeks to go until lb is one 16:43:33 maybe apmelton can help on that 16:43:41 what's that? 16:43:46 I think madhuri has python-k8sclient under hand 16:43:50 pause for just a moment 16:43:51 external-lb 16:44:02 sdake_: I am doing some prototyping now, 16:44:04 let's wrap discussion of this BP 16:44:14 and then we can dive into external-lb 16:44:49 joffter and I will look at #1/#2 and see if we can contribute to any. 16:44:50 so on the swarm related BP's we are going to leave them at the current priorities 16:44:53 i have a question re this bp then, with it we get swarm bays? 16:45:11 this is one of a tree of PB's for that purpose 16:45:20 s/PB/BP/ 16:46:00 ok, so let's take a quick look at the other top BPs now 16:46:09 as we are nearing the ned of our scheduled meeting time 16:46:11 thanks jjlehr, let me know if you have any questions 16:46:25 #link https://blueprints.launchpad.net/magnum/+spec/external-lb External LB 16:46:41 apmelton: I definitely will :) 16:46:43 without this, k8s in magnum is not really usable 16:46:44 thanks jjlehr and joffter 16:46:56 its not a deployment issue, its a play issue 16:47:05 agreed 16:47:44 landing this feature will result in a better outcome for Magnum when folks learn about Magnum in Vancouver and start to try it out 16:48:10 Does it make sense to break this into smaller chunks? 16:48:16 it's currently scoped as a Large 16:48:28 so we should work on splitting it up 16:49:11 in Announcements I forgot to mention something 16:49:19 sorry! here it is: 16:49:57 sorry got late for meeting 16:49:58 sdake_ and I are in contact with the leaders of the Kubernetes project. We have agreed to work together to make a good Kubernetes+OpenStack outcome. 16:50:10 they agreed to collaborate openly with us on the subject of external-lb 16:50:16 which was our first ask 16:50:24 hi diga_ 16:50:27 awesome! 16:50:32 cool 16:50:42 Hi adrian, 16:50:51 one thing to keep in mind is the kubernetes core team is overloaded - 850 PRs a month 16:50:52 so we plan to have some topic-specific discussions about that impelementation 16:51:05 so i'm not sure how much they can help in the next 2 weeks :) 16:51:13 and I intend to get that rolling soon, in efforts to get implementation in by 4/25 16:51:31 at the very least we can get clarity on what may be changing upstream in relation to this feature 16:51:37 and act accordingly 16:51:39 agree 16:51:50 I will take an action on that 16:52:15 #action adrian_otto to poll participants for a discussion with k8s devs about external-lb feature 16:52:18 tango do you need help? 16:52:33 so I will circulate a Doodle to help schedule IRC meeting(s) for that 16:52:33 I am getting some help from a colleague on the networking aspect 16:52:53 but I can use some help on clarifying the Kubernetes side 16:53:09 ok, so let's do our best to land that soon 16:53:16 and then finally, we have this one: 16:53:27 tango lets chat in openstck-containers after the meeting 16:53:35 #link https://blueprints.launchpad.net/magnum/+spec/secure-kubernetes Secure Kubernetes 16:53:46 to finish the job on that one we need two things 16:53:47 this is about adding TLS support 16:53:53 #1) documentation on how to secure kubernetes 16:53:58 I obtained that the last week 16:54:04 and this one is important to land but not as critical as the external-lb 16:54:12 #2) TLS support is not built into swagger, so we have to add it manually 16:54:53 #3 heat templates need to be changed to generate tls keys and output certificates 16:55:12 #4 kubernetes has to read certificates from heat outputs and configure python-k8sclient appropriately 16:55:50 sdake_: does heat have x509/openssl resources? 16:56:09 pretty sure not 16:56:16 we may have to generate them in the client and pass them in 16:56:48 sdake_: we can ping randallburt about that one 16:56:51 we need to add TLS support to container api also 16:57:00 ya more fuel for the fire! :) 16:57:11 which'll mean updating the docker-swarm templates for tls 16:57:15 yep 16:57:20 that should be a separte blueprint secure-docker 16:57:31 yes 16:57:33 #topic Open Discussion 16:57:38 we have a little time left 16:57:42 bandit gating 16:57:53 i'm going to change the experimental bandit gate to a nonvoting check gate 16:57:55 any objections? 16:58:00 +1 16:58:14 +1 16:58:16 after we release i'm going to change it to a voting check+gate ;) 16:58:18 +1 16:58:20 +1 16:58:24 there is rally no downside to it 16:58:28 *really 16:58:39 the voting part could be a downside, but bandit is pinned and seems reliable 16:58:50 +1 16:59:01 +1 16:59:20 #agreed to make bandit a nonvoting gate, upgraded from experimental 16:59:47 Our next meting is 2015-04-21 at 2200 UTC 17:00:15 I look forward to seeing you all there. Please join us in #openstack-containers for follow-up discussion 17:00:25 thanks everyone 17:00:26 #endmeeting