16:02:22 #startmeeting containers 16:02:22 Meeting started Tue Mar 31 16:02:22 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:02:23 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:02:25 The meeting name has been set to 'containers' 16:02:28 #link https://wiki.openstack.org/wiki/Meetings/Containers#Agenda_for_2015-03-31_1600_UTC Our Agenda 16:02:33 #topic Roll Call 16:02:34 Digambar Patil 16:02:36 Adrian Otto 16:02:37 o/ 16:02:40 o/ 16:02:51 o/ 16:03:26 o/ 16:03:30 Steven Wilson 16:03:41 Thomas Maddox 16:03:47 sdake: before I get to the announcements section, are you willing to chair on 4/7 at 2200 UTC? I will be out on that day. 16:03:52 Perry 16:03:58 adrian_otto ack wfm 16:04:02 tx 16:04:41 hi 16:04:54 hey tango 16:04:58 just the cat I wanted to talk to :) 16:05:03 can you hit me up after the meeting 16:05:07 Hi Steve 16:05:14 sure 16:05:21 hello diga, apmelton, hongbin, sew1, thomasem, juggler, sdake, Tango|2 16:05:29 #topic Announcements 16:05:59 1) I will be away on 2015-04-07, so sdake has agreed to char for us for our team meeting on that day. 16:06:07 2) Elections 16:06:23 we will be part of the OpenStack elections for PTL, so we will not be conducting our own election. 16:06:34 3) Design Summit 16:06:55 Magnum will have it's own "track?" at the Vancouver Design Summit 16:07:33 soon there will be a call for topics, so keep an eye out for that. I am open to proposals from all of you. I know that container networking would be a good one to put high on the priority list 16:07:47 any questions about the announcements above? 16:07:51 agree on container networking 16:08:01 election dates 16:08:12 when are they ? 16:08:22 adrian_otto: I want to volunteer for the container networking 16:08:41 #link https://wiki.openstack.org/wiki/PTL_Elections_April_2015 Election Details 16:08:43 suro-patz y ou have to know what your volunteering for first :) 16:08:52 sdake: the above link has the specifics about that 16:08:54 sdake lol 16:08:56 if you guys can put more description of the problem it will be better 16:09:05 adrian_otto I know the dates was for benefit of others ;) thanks 16:09:22 suro-patz we dont have a better description :) 16:09:23 suro-patz: yes, that will be a big deal to get right 16:10:09 we will need to do a focusing exercise to put a label on our long term vision, and an incremental plan to advance us toward it in small steps 16:10:32 but at a very high level, we want it to be easy to link containers across a network in a way that is consistent with other tools 16:11:18 yes, that is required now onwards 16:11:32 any other announcements from team members? 16:11:52 I got one 16:11:56 I will mention for those of you who missed the last meeting... 16:11:58 sorry to cross-spam :) 16:12:06 sdake: just one sec 16:12:27 Magnum has joined the OpenStack projects list, and has moved from the stackforge git namespace to the openstack git namespace. 16:12:40 if you have any questions about that, please see me, and I'd be happy to help. 16:12:45 sdake: all yours. 16:12:47 The kolla effort (containerize openstack) has created a new irc channel #kolla - please join if you have interest in containerizing openstack 16:12:55 also python-magnumclient has moved as well :) 16:13:16 yes! I should not treat it as a stepchild 16:13:36 #topic Review Action Items 16:14:05 1) ACTION: adrian_otto to check to see if Magnum may participate in the April 4 - April 11: PTL elections. (http://eavesdrop.openstack.org/meetings/containers/2015/containers.2015-03-24-22.00.log.html#l-261, 22:51:25) 16:14:13 Status: Completed. See above. 16:14:23 sure sdake 16:14:29 #topic Blueprint/Task Review 16:14:56 this is the section where we can discuss any blueprint or bug/task ticket 16:15:15 we have a new blueprint worth mentioning. diga, do you want to present it? 16:16:15 adrian_otto: you know that work, I think you can initiate 16:16:30 ok, getting the link. one sec 16:17:03 https://blueprints.launchpad.net/magnum/+spec/add-glance-image-properties-supporthttps://blueprints.launchpad.net/magnum/+spec/add-glance-image-properties-support 16:17:19 type mstake - https://blueprints.launchpad.net/magnum/+spec/add-glance-image-properties-support 16:17:23 see this 16:17:45 #link https://blueprints.launchpad.net/magnum/+spec/add-glance-image-properties-support Add Glance Image Properties support for Magnum 16:18:28 ok, so this is a follow-on from last weeks conversation about BayModel, and expansions on that concept to support multiple bay types 16:18:47 diga_ looks good to me +2 :) 16:18:56 apmelton has a WIP review up for some work he is doing in this area 16:19:03 defintiion need to go to approved 16:19:17 diga agreed to check in with apmelton 16:19:29 thanks sdake 16:19:51 I'm not worried about duplicate work, but if you both know what each is doing, maybe we can avoid nonproductive overlap 16:19:54 yes adrian_otto 16:19:58 agreed 16:20:04 diga_ and apmelton do you need anything from the team? 16:20:40 I think the integration point for these pieces is around the cluster_type option, and I haven't really touched that 16:20:40 I think both of us know our area of work 16:20:45 question diga 16:20:47 not for now 16:20:55 ok, feel free to raise this up if you need further input 16:20:58 once this patch is in, coreos will support what exactly? 16:21:10 the container api or the pod api? 16:21:36 sdake: it will allow you to run kubernetes pods (bays) on coreos nodes 16:21:57 yes 16:21:58 I don't think this reaches the container api 16:22:10 sweet! 16:22:13 my internet is bit slow :) 16:22:14 i'm super excited to try it out 16:22:40 didn't know coreos integretaed k8s directly 16:22:43 or the template configured it - which is a pita typically :) 16:22:44 there is support for coreos in there now, but we want to improve it further before pushing it 16:23:18 #link https://blueprints.launchpad.net/magnum/+spec/simplify-api-model 16:23:40 this blueprint will require moving things that are in the api handlers into the rpc handlers 16:23:43 aha, yes. 16:23:47 things like "which data to print out" 16:23:47 etc 16:23:56 so ai'm good with it, but it breaks abstraction a bit 16:24:19 explain more about the breakage? 16:24:38 we'll still have the same abstractions, we are just consolidating the parts they have in common, right? 16:24:40 sec let me find example 16:25:10 same abstractions, storing in their same places in the db, but with one api 16:25:54 for example this needs to come from the rpc server 16:25:56 https://github.com/openstack/magnum/blob/master/magnum/api/controllers/v1/pod.py#L72 16:26:00 that's fine with me. Does anyone else have concerns about that? 16:26:14 there are *many* more exmples 16:26:20 but it means our rpc api will become a bit more complex 16:26:40 are there other approaches we should consider? 16:27:10 not sure - might be able to walk the object list - not certain how the versioned jobjects interacts with the rest api 16:27:11 having a complex RPC API really only means that it's more difficult to extend Magnum as a Magnum developer 16:27:13 they are meant to be a 1:1 mapping 16:27:25 well we are talking 2-3 more extra calls 16:27:35 so its not deadly 16:27:54 for example I need a "get_fields_unset" api call 16:28:02 (I think?) 16:28:27 another option is to store those fields in the db 16:28:59 so the point of this is to unset fields for non-detail calls? 16:28:59 sdake: maybe store them under 'extra' field 16:29:01 I"m not sure, I'll have to sort it out 16:29:02 like list calls? 16:29:14 apmelton right 16:29:24 but there are other parts of the api which are model specific 16:29:36 so wait a sec 16:29:40 and only the parser (in the rpc handler) knows about 16:29:54 the reason we are contemplating this to begin with is to simplify the object model, right? 16:30:05 the api model 16:30:12 the object model as is rocks 16:30:13 and to get that simplification, we need to add complexity to the RPC API 16:30:31 are we actually reducing the overall complexity, or just moving it around? 16:30:47 api, model, thanks. 16:30:48 moving it around away from where the user sees it to where they dont see it (abstraction) 16:31:05 ok, so net benefit to API users 16:32:31 I just want to be cleear upfront 16:32:32 ok, I'm happy with that. Any further discussion on this sub-topic? 16:32:40 after digging into this problem for awhile 16:32:46 I am not sure if it is even possible to do - and maintain versioned objectss support 16:32:57 imo versioned objects is more important then simplifiying the pai 16:32:58 api 16:33:05 agreed 16:33:17 +1 16:33:21 so if Iget to the point when I know it wont work 16:33:25 we may have to abandon the spec 16:33:34 I'm just not sure yet 16:33:41 ok, cool 16:34:05 re 16:34:19 I wanted to talk about tango|2's blueprint 16:34:30 ok 16:35:00 #link https://blueprints.launchpad.net/magnum/+spec/external-lb 16:35:08 yep 16:35:24 can you give us a progress update - at the summit it sounded like k8s changed how all this works 16:35:31 sorry midcycle 16:35:56 and I've heard that from others as well 16:37:02 I am just starting on this, had to clear a number of things on my plate before diving into Magnum 16:37:09 oh, I failed to mention that Mark Collier (re) introduced me to the project manager for Kubernetes, Greg Mcluckie. We are having a concall on Friday morning on the topic of Kubernetes and OpenStack working together better. 16:37:25 if there is anything I can bring to the agenda to help us, please let me know. 16:37:41 but you did mention that it changes, so I am going through the new details 16:38:54 My plate is clear now, so I will be focusing on the blueprint 16:39:04 ok, Tango|2 is there any chance you will have a look at it before friday morning? 16:39:27 yes, I am working on it now 16:39:32 I can probably connect you directly with the person(s) working on that in k8s 16:39:40 in case you have any questions 16:39:41 that would be very helpful 16:39:46 adrian_otto: good to know 16:39:51 #google-containers irc channel is best way to reach the devs 16:39:51 ok, I'll be sure to ask about that 16:40:16 i recommend everyone add it to their irc clients ;) 16:40:33 thanks sdake. Good suggestion. 16:40:47 +1 sdake 16:41:01 We have a bunch of blueprints in New status 16:41:17 I plan to start looking through all those this week 16:41:37 so if there are ones you take an interest in, please subscribe and we can start fleshing them out a bit 16:41:39 adrian_otto I added the secure kubernetes blueprint to the cycle 16:41:44 but it looks like it got unadded 16:41:49 a yahoo cat was going to work on it 16:41:51 hummm 16:42:16 ok, I will put that one at the top of my list 16:42:20 has to do with adding tls support to client/server 16:42:26 seems essential to me 16:42:33 if we have the bandwidth to do the job 16:42:57 yeah, that's a good one 16:43:17 he was looking for a 40-80 hr blueprint to work on 16:43:21 and that seemed to fit the bill :) 16:43:22 does it also include some solution the key management? 16:43:40 we have to add the client keys to the db in some way 16:43:44 generating the client cert, and putting the corresponding parts on the remote? 16:43:51 and automate the key transfer is python-k8sclient 16:44:02 not sure if madhuri knows if tl supported in the work she is doing or not 16:44:19 madhuri should be at our next meeting, I think. 16:44:21 adrian_otto yup that is my thinking of how it shoud work 16:44:35 ya middle of night for her - but like her work so far! 16:44:43 yes, that would be a solid feature 16:44:55 if tl/if tls 16:45:04 sdake: +1 she has been doing very good work 16:45:47 ok, I'm planning to enter OpenDiscussion in a moment, but before we do, are there any other work items that need team discussion today? 16:46:35 #topic Open Discussion 16:46:56 so lets just congratulate ourselves one more time for incubation 2.0 :) 16:47:04 * adrian_otto applause 16:47:04 its so huge, its not even funny :) 16:47:06 \o/ 16:47:28 yea! 16:47:31 next step is tagging 16:47:32 winning! 16:47:34 http://i.imgur.com/YqhPmjQ.gif 16:47:45 ^^ +1 16:47:55 apmelton epic movie :) 16:48:03 anchorman ftw 16:48:16 :D 16:48:34 I am happy to see new contributors streaming in… we now have 35 engineers who have merged code in our repo… representing 19+ affiliations 16:49:12 that's reviewers… let me revise for committers 16:49:21 its a party time for magnum team :) 16:49:49 32 engineers from 17+ affiliations 16:50:23 and the trend I am seing is that these are not just OpenStack contributors migrating over from other projects… these are new contributors joining the OpenStack ecosystem 16:50:43 growing openstack atc = winning :) 16:50:54 :) 16:51:35 so for all of you who have joined us recently, we are happy to have you! 16:52:13 how do you all feel we are doing with review throughput 16:52:30 do you feel like you are getting helpful feedback on your work in a timely fashion? 16:52:40 definitely 16:52:55 yes 16:53:13 review throughput is very fast in this project 16:53:17 and are we efficiently merging code that you think is ready? (not putting you through revision patchset hell) 16:53:21 fastest I have ever seen in any project 16:53:39 agreed 16:54:00 I have something a bit controversial 16:54:02 to discuss 16:54:18 I'm finding it harder and harder to keep track of development 16:54:26 the way projects solve these problems is through the specs process 16:54:33 yes, I think it's healthy, but we can still check for areas to improve 16:54:40 I think its too early in magnum's lifecycle to do spec 16:54:50 but we might want to think about it towards the end of liberty 16:55:38 sdake, so one idea might be to have a weekly review of merged code in the team meeting, or on the ML 16:55:47 so around l3 - possibly introduce specs 16:55:57 with the idea we will do specs in M 16:55:58 so you could get some picture of what's happening week by week if you're not doing reviews every day 16:55:59 just a thought :) 16:56:10 I do reviews every day 16:56:22 so what's the visibility you feel is missing? 16:56:27 and can't keep up with development - this causes the core reviewers to lose context 16:56:34 is it that we merge it before you see it? 16:56:36 the reviews happen so fast I miss ones that hit the repo 16:56:44 ok, I understand 16:57:07 so what about a summary? 16:57:16 sounds like a pita to maintain :) 16:57:23 I can live with it for now 16:57:29 but I expect by end of liberty we will have 100atcs 16:57:35 one hundred that is 16:57:50 and that was hard to handle for heat 16:57:57 (the context maintenance) 16:58:11 in retrospect I wish for heat we had a specs process when our atcs hit the 100 mark 16:58:24 and that slows down velocity 16:58:35 specs does slow down veloicty 16:58:40 so not proposing for liberty 16:58:41 I will think on that further 16:58:45 but possiby end of liberty 16:58:49 ya everyone giveit some thought 16:58:56 ok, we can talka bout that at the summit too maybe 16:59:08 we have a few minutes left 17:00:26 our next meeting is 2015-04-07 at 2200 UTC. sdake will chair. Enjoy! 17:00:30 #endmeeting