00:02:37 #startmeeting CongressTeamMeeting 00:02:39 Meeting started Thu Apr 21 00:02:37 2016 UTC and is due to finish in 60 minutes. The chair is thinrichs. Information about MeetBot at http://wiki.debian.org/MeetBot. 00:02:40 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 00:02:42 The meeting name has been set to 'congressteammeeting' 00:03:47 My agenda for today... 00:03:49 1. Austin 00:03:57 2. distributed arch 00:04:08 3. action items from last week 00:04:16 Anything else? 00:05:51 #topic Austin 00:06:03 Most important item for the day :) 00:06:08 ekcs: how are the dinner plans going? 00:06:27 Food: I'm thinking this place: a nice texas BBQ place about 10 minutes walk away (we can take a cab if it's too hot to walk). What do you guys think? #link: http://www.lambertsaustin.com/menus/ 00:06:34 Scheduling: Monday and Tuesday there are evening events. So I'm thinking either Wednesday or Thursday (maybe depending on which day the cores have core party). What do you guys prefer? 00:08:50 texas BBQ sounds delicious... 00:08:56 ramineni: how does that menu look for you? 00:10:34 thinrichs: looks ok .. we can go for it 00:11:06 I was trying to check into the core approver party; couldn't find an email; maybe I wasn't invited or maybe there isn't one? 00:11:23 their non pork/beef items are: Half Local Chicken, Cold Smoked Rainbow Trout, Fresh Market Gulf Fish, Jumbo Gulf Shrimp & Grits, Cold Smoked Lockhart Quail, ... 00:11:53 I'd lean toward Wed, since we'll have finished all our sessions that day. Seems a good reason to celebrate. 00:12:17 But both should be fine, as long as they're after 6p. 00:12:53 I prefer Wed, but of course both work for me. 00:13:04 ekcs: thanks :) , sounds good 00:13:32 ekcs: never tried that kind of dishes though :P 00:13:38 ekcs: thanks for doing the research. Looks delicious! 00:13:52 ramineni: it'll be an adventure for all of us, I'm sure. 00:14:19 thinrichs: yes :) 00:14:53 ekcs: can we get reservations? 00:14:58 both works for me too 00:15:05 wed and thurs 00:15:34 ok so we’re going with Wednesday then? Yea that was one of my requirements: that they take reservation. 00:15:45 places would be packed during convention nights. 00:15:48 ekcs: Yes to Wed 00:16:20 Heard no objections and 2 prefs for Wed 00:17:14 ok then! 00:18:07 On with the other Austin items... 00:18:29 We have a meeting scheduled with Vintrage for 3-4p on Thu. Location unknown. 00:19:04 #link https://wiki.openstack.org/wiki/Vitrage 00:19:39 That's right after a series of talks on Congress and similar projects. 00:20:07 Wed our sessions run from 11-3:30p 00:20:30 Search for "Congress" on the schedule for more details. 00:20:31 • https://www.openstack.org/summit/austin-2016/summit-schedule/global-search?t=congress 00:21:26 Great! 00:21:46 The sessions we're planning on are focused on (i) integrations with other projects (fabiog's Monasca and policy-aware nova scheduling are on the agenda) 00:22:14 (ii) appraising the state of the distributed arch and what we need to do to get the first version running 00:22:50 (iii) a session for pair programming to knock off some of those todos 00:23:16 (iv) a session on designing the deployment to achieve high availability and high throughput using the distributed arch 00:23:23 What do we think of that? 00:23:45 Is it worth having a programming session? Or is there another topic we should consider? 00:24:47 For example, we could discuss priorities for non distributed-arch work for the upcoming cycle… 00:25:17 e.g. horizon plugin, adding keystone session support to our client (if we don't have it), etc. 00:25:34 Hmmm. 00:26:23 If we think we can switch over to new_arch in-mem while we’re there, that would be really cool to do. 00:26:58 Or brain storming for another feature? 00:27:09 but not sure it’s best use of work session time because I’m not sure how much coordination we need. for that. 00:27:30 ekcs: agreed 00:27:53 masahito: maybe talking through the push driver and trying to figure out how to make it work for any schema? 00:28:29 ya, or may be we could plan/discuss for possible working items/features targeted for next release apart from dist_arch 00:29:03 thinrichs: that's sounds nice. 00:29:38 ramineni_: agreed 00:29:38 thinrichs: I think it's not need to use whole one session for the topic. 00:30:00 Let's use one of the sessions then to discuss non dist-arch features in the upcoming release. 00:30:30 great. 00:30:31 That means everyone should come to the meeting with features they would like to see finished in the next cycle. 00:30:58 #action Everyone will prepare a list of features to consider developing in the next cycle 00:31:21 #action thinrichs will update the session description 00:32:40 Also for the High availability and High throughput session, 00:32:58 everyone should think through how we might deploy Congress assuming the new distributed architecture is in place 00:33:38 We want to start that discussion with everyone already having spent a few hours thinking through the issues. 00:33:58 great. 00:34:05 #action Everyone will come up with a design for deploying Congress to meet High availability and high throughput requirements 00:34:42 That's it for me on the Austin topic. Anything else? 00:34:44 back to dinner real quick, what’d be a good time? 6:30? 7? 00:35:11 I'd say 6:30 00:35:15 6:30 00:35:33 okay. 00:37:23 Seems I was disconnected for a bit. 00:38:04 Did anyone else vote while I was gone? If not let's say 6:30p 00:38:30 ramineni_: said 6:30. didnt hear from masahito 00:39:14 Seems IRC is having some trouble. 00:39:18 masahito: you still here? 00:39:23 tsandall: how about you? 00:39:25 yes 00:39:27 i'm here 00:39:32 6:30pm is fine for me 00:39:47 6:30 works 00:39:50 Ok, so let's go with 6:30 and hope IRC stays up 00:40:05 Moving on... 00:40:14 #topic distributed-arch 00:40:29 We're pushing code on this again, which is good. 00:40:51 Shall we do quick status updates, bringing up discussion points as we go? 00:40:56 masahito: want to start? 00:41:14 yes 00:41:52 I pushed codes which enables Congress start with distributed_arch flag is true 00:43:04 because of some constraints the flag didn't work correctly if we set True in devstack before the patch. 00:43:32 that's from my side. 00:44:45 ramineni: want to go? 00:45:22 thinrichs1: no, havent had much progress on dist_arch this week, have worked only on gate failures 00:45:57 ramineni_: anything you've been working on here is good, not just dist_arch 00:47:07 thinrichs1: ok, and I have worked on the action items of last week 00:48:09 thinrichs1: thats it from my side 00:48:35 Anything to report on the action items? 00:49:44 Running short on time... 00:49:50 ekcs: status update 00:50:00 thinrichs1: now the gates should be green , after the fix we thought of skipping ceilometer tests on stable branches 00:50:16 thinrichs1: all green for now 00:50:26 ramineni_: great! 00:50:38 sequenced, differential update in dse2: #link: https://review.openstack.org/#/c/304991/ 00:50:39 Key issue is whether to put the sequencing logic in DseNode or DataService. The patch has it in DataService, but Masahito suggested putting into DseNode. I agree it's a good idea. 00:50:40 (un)subhandler for dse2: #link: https://review.openstack.org/#/c/285628/ 00:50:40 Main discussion issue is whether to check for changes to which tables have subscribers on each heartbeat, or check only when (un)subscribe_table makes an RPC call to the publishing DataService. Masahito feels it is wasteful to check on every heartbeat. But I think the additional cost is not a significant issue. 00:52:25 differential update: top priority for me is hiding that from the datasource/policy-engine code 00:53:09 Might be valuable down the road to enable a datasource to overload the wire-protocol being used, which would mean the code needs to belong to the DataService. 00:53:30 Nothing jumps to mind as to why it's better in the DseNode 00:53:54 thinrichs1: agreed. both approaches makes it transparent to the drivers and policy engines. 00:54:46 unsubhandler: I'd start with the simpler code that ensures the behavior is correct. 00:55:05 Optimizing too much as this point is worrisome until we have everything working end-to-end. 00:55:14 So I'd lean toward correctness over speed right now. 00:55:23 thinrichs1: the main reason for putting into DseNode would be to avoid duplicating data structure and processing when multiple DataServices is the same node subscribes to the same tables. But I don’t think it’s very significant, if you think there is a reason for datasource to override. 00:55:25 Easier to optimize once we have correctness and tests in place 00:56:06 masahito had another reason he preferred it in DseNode but I didn’t quite understand that reason. 00:56:28 ekcs on differential updates: that makes sense. Seems that the DseNode is a better place for the code. 00:56:46 Quick update from me, as we're short on time… 00:56:59 ekcs: I'll put the details about it on gerrit. 00:57:22 I'm working on a new harness that stitches together the API, datasources, and policy engine so they're running on the Dse2. 00:57:29 Main change is that… 00:57:51 All of the API models are no longer DataService instances; they are all combined into 1 DataService. 00:59:09 Did that since the API router can then multiplex to the proper model without sending a message on the bus 00:59:47 The model still sends messages on the bus to the datasource or policy engine, of course. 01:00:07 #link https://review.openstack.org/#/c/280424/ 01:00:12 Out of time for today. 01:00:23 We're cancelling next week's meeting since we'll all be in Austin 01:00:34 Looking forward to seeing everyone face-to-face next week! 01:00:36 Safe travels! 01:00:39 awesome 01:01:09 #endmeeting 01:01:11 see you in Austin! 01:01:33 #chair thinrichs1 01:01:36 #endmeeting 01:02:05 #endmeeting 01:03:20 #endmeeting