00:01:12 #startmeeting CongressTeamMeeting 00:01:14 Meeting started Thu Jan 21 00:01:12 2016 UTC and is due to finish in 60 minutes. The chair is thinrichs. Information about MeetBot at http://wiki.debian.org/MeetBot. 00:01:15 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 00:01:17 The meeting name has been set to 'congressteammeeting' 00:01:26 hi 00:01:48 hi 00:01:54 Here's my topic list this week… 00:02:01 1. mitaka2 00:02:04 hi 00:02:04 2. distributed arch 00:02:17 3. midcycle summit 00:02:31 4. push datasource driver 00:02:36 5. other status updates 00:02:40 Anything else? 00:03:31 Let's get started then. If something else comes to mind, let us know. 00:03:35 #topic mitaka2 00:03:47 I just released mitaka2 earlier today 00:03:56 So we're now working on the mitaka3 release. 00:04:37 I went through and moved all the blueprints that I know we're actively working on to mitaka3 00:05:06 If I missed any, please target them to mitaka3 so we have a sense of the code we expect to land. 00:05:22 #link https://blueprints.launchpad.net/congress 00:05:42 Any questions or comments about mitaka? 00:07:11 Moving on then... 00:07:14 #topic distributed arch 00:07:29 pballand: I saw you pushed some comments/code earlier today but haven't had a chance to look. 00:07:32 How's it going? 00:07:48 slow but steady 00:07:54 I was hoping ekao would be here 00:08:03 I’m here. 00:08:15 ekcs: hi :-) 00:08:56 ekcs is looking at the datasource interface to add to DataService, I’ll let him talk about that proposal - I’m working through comments 00:09:10 general theme is that it is weird to have so many topics - which I agree 00:09:48 unfortunately oslo.messaging logs exceptions if it receives an RPC for an endpoint that it doesn’t have, *even* if the RPC has a different namespace or version 00:10:28 I had a question. Not sure if you answered it in the comments. 00:10:33 if anyone has a different suggestion than using separate topics, I’m open (we can also discuss next week) - otherwise I am continuing on the current path since it is functional 00:10:41 What is the control bus used for? 00:11:18 the control bus is used for service discovery and status 00:11:52 for example, if I am a policy or api service, I may want to know what services and tables exist - those are tracked by the control bus 00:12:42 form the dist-cross-process-dse spec: “ A common directory of data services and their exported tables must be 00:12:43 published to all services on the DSE.” 00:13:21 does that answer your question? 00:13:36 Not quite 00:13:57 Do we have code today that asks "give me all the tables" or "give me all the services"? 00:14:16 Or will we need to ask that question in the distributed arch? 00:14:32 The APIs that list tables make RPCs directly to the service 00:14:33 the API will need that information 00:14:44 the API needs to know what services there are 00:15:16 So if we have an API that asks for the list of available datasources, then it will ask the control bus. 00:15:23 That makes sense. 00:15:58 I think that's a feature we deprecated, so we won't need it for the upcoming release, but we'll want it once we start putting the datasource APIs back in place. 00:16:16 right - we _could_ have the API service broadcast the question on the bus, but it seems better to me to have a common component 00:17:04 Does anything else need the bus? I think the policy engine just subscribes to tables and hopes they exist or will exist. 00:17:14 s/bus/control bus/ 00:17:59 So I'm thinking that once we have pub/sub added to the existing rpc, we can do the integration work. 00:18:08 Even if the control bus hasn't been merged. 00:18:20 Does that sound right to everyone? 00:19:38 I agree for the integration. 00:19:52 ekcs: want to go over your proposal? 00:20:16 ok 00:21:20 I have a preliminary implementation of this bp: https://blueprints.launchpad.net/openstack/?searchtext=dist-datasources-on-bus 00:21:54 where pub-sub messages are sequenced and reordered etc. at the datasources and policy engines. 00:22:31 but pballand and I thought it makes more sense to build the functionality straight into the DataService class (replacing current deepsix) 00:22:35 Any thoughts on that? 00:23:17 That sounds like the right abstraction to me. 00:24:00 Just a sanity check: does oslo-messaging handle any of this? 00:24:16 If we just use the existing pub/sub, does it not guarantee in-order delivery? 00:24:28 agreed: should simplify transition from deepsix if we have the exact same interface 00:26:48 As far as I understand, it depends on the underlying transport. RabbitMQ for example doesn’t guarantee order. 00:26:59 Another question: can we proceed with the integration work using the native pub/sub? 00:27:31 And in parallel provide the guarantees we want? 00:27:48 what do you mean by native pub/sub? 00:27:52 How often do out-of-order problems happen? 00:28:01 pballand: doesn't oslo-messaging have pub/sub functions? 00:29:13 oslo-messaging has a ‘Notifier’, but it doesn’t seem to line up well with the DSE 00:30:23 other that that, the only pub/sub like function I am aware of is “casting” RPCs 00:30:41 So we're still missing pub/sub functionality? 00:30:41 which is what my impl is using 00:31:26 thinrichs: Notifiers does implement a publisher 00:31:31 but it is a fire and forget one 00:32:08 all the services in OpenStack uses the Notifier to send events 00:32:26 pballand: I think client.cast() with funout=False works as a base function of pub/sub. 00:32:36 masahito_: agreed 00:33:19 masahito: how long do you think it would take to build pub/sub on top of client.cast()? 00:33:39 We can always improve the pub/sub implementation, but all of the integration is blocked on having basic pub/sub functionality? 00:34:00 my proposal (which I believe is inline with what ekcs is proposing) is to add the existing deepsix interface to DataService using the RPC methods exposed by what I have in review 00:34:17 How long will that take? 00:34:43 thinrichs: I think it takes less than one day. 00:35:27 thinrichs: because pballand have implemented a similar function in dsenode. 00:35:36 pballand, ekcs: how long do you think your proposal will take? 00:35:59 I think it’s reasonable to have it before the midcycle next week 00:35:59 Is it worth having masahito try to get something in place and then upgrade it to your version once its ready? 00:36:23 I welcome any help, especially from masahito_ :-) 00:36:36 thinrichs: no reason to have two versions... 00:37:01 pballand: sure, but the plan was to have us all try to do some basic integration work before the cycle. 00:37:28 thinrichs: at least a week I think. getting everything in deepsix to work on dse2 could have many issues come up. 00:37:52 i was about to say earlier that it could be an issue to out time line. 00:38:47 We've been blocked on this piece for a long time. 00:39:04 I think it's worth the cost of some replicated work to ensure we make progress. 00:39:18 just to make sure we are on the same page: the work is to tie together the deepsix interface (~ 12 methods) on top of the DataService RPC interface 00:39:40 is that right? 00:40:16 pballand: That's always been the basic problem, hasn't it? the DataService RPC interface is incredibly similar to the oslo-messaging interface, right? 00:40:32 At the very least, the 3 of you will have the experience necessary to trade war stories next week. 00:40:47 pballand: I think putting deepsix interfaces into dataservice would take days. and then implementing reliability and message ordering would take days on top of that. 00:41:40 It's time to move on I think. 00:41:42 maybe we need to talk to masahito_ some more to understand what he’s proposing to do in less than a day. so we understand where we differ and how to proceed. but in either case if it takes less than a day it’s not a great cost. 00:42:18 ekcs: agreed. Would you want to talk/irc with masahito offline? 00:42:40 thinrichs: yea. pballand can you join too? 00:42:45 yup 00:42:59 yap 00:43:11 Great! Thanks you 3. 00:43:16 #topic midcycle summit 00:43:23 Just a reminder that the midcycle summit is next week. 00:43:31 fabiog: any comments here? 00:43:47 yes 00:43:49 Have you heard about the monasca summit? Are we overlapping? 00:43:59 no 00:44:15 Monasca is going to be held the following week virtually over webex 00:44:27 there are a lot of people in EU that won't be able to travel 00:44:37 for our mid-cycle is everyone confirmed? 00:45:04 I currently have: thinrichs pballand masahito_ ekcs and me 00:45:23 That could be about right. We knew it would be a skeleton crew this year. 00:45:31 Someone from solinea was planning to stop by for a day. 00:45:39 ok for the logistics 00:45:42 this is the address 00:45:48 Cisco Systems, Inc. 285 W. Tasman Drive San Jose California 95134 United States 00:46:04 I was thinking on a 9:30am PDT start 00:46:17 #link https://wiki.openstack.org/wiki/Sprints/CongressMitakaSprint 00:46:17 we can meet at the lobby and I will escort in 00:46:53 su_zhang: are you planning to attend the mid-cycle summit next week? 00:47:20 fabiog: sounds good 00:48:03 ok, on Wed evening I was planning to have a group dinner. If Wed is no good for someone we can do it on Tue, is Wed good? 00:48:35 Wed works for me. 00:48:47 So does Tue 00:49:01 any type of food/restaurants I should avoid? 00:49:02 both good for me. 00:49:15 both works for me. 00:49:25 fabiog: building D 00:49:39 actually tue would be much better for me, 00:49:40 ijw: nope, building I (eye) 00:49:51 Yeah, you should avoid building D, it's full of Cisco ppl 00:50:01 Woudln't want to eat there 00:50:18 ijw: no worries we will have catering at our meeting room 00:50:24 breakfast included 00:50:24 pballand: can you make it for dinner Tue/Wed? 00:50:33 sounds great 00:50:45 Tues is better for me too 00:50:56 Sounds good. 00:50:57 Ok, then, I will book for Tue 00:51:29 fabiog: are you still planning on discussing a deeper monasca integration? 00:51:59 thinrichs: yes. Even if I am completely blocked by the integration of Monasca client in Openstack 00:52:25 sounds good 00:52:33 We're running short on time. 00:52:54 Before I forget we'll cancel next week's IRC since many of us will be at the sprint 00:53:00 I'll send an email to the ML. 00:53:06 #topic status updates 00:53:15 masahito: how is your push datasource driver going? 00:53:20 ramineni: any status updates to report? 00:53:31 (Go ahead and interleave your answers, since we have 7 min left) 00:53:44 slow progress this week. 00:53:51 If anyone else has status updates/comments/questions, now is the time. 00:54:31 thinrichs: nothing much from my side, 00:55:05 @thinrichs: yes 00:55:12 ekcs: did you get your latest python3 patch sorted? Is there anything we should discuss here? 00:55:15 I'm checking OPNFV usecase for push driver. and try to push next patch set before sprint because I guess Monasca want it feature for the integration. 00:55:36 @thinrichs: I will be in the meeting 00:55:38 fabiog: we have another attendee: su_zhang. I'll check eventbrite and see if anyone else signed up. 00:55:58 look forward to seeing you guys there 00:56:02 thinrichs: ok, great. 00:56:03 thinrichs: yup. I moved the imports to below the copyright statements. and masahito_ decided his comment wasn’t an issue. 00:56:05 s/it feature/the feature/ 00:56:06 su_zhang: great! We're looking forward to seeing you again and hearing how Congress is working @Symantec. 00:56:19 sounds great! 00:57:05 ekcs: sounds good 00:57:07 ekcs: oops, I forgot change review status. 00:58:01 masahito_: sounds good. I don't think there's a ton of pressure to have your code merged before the sprint, but another iteration makes sense. 00:58:57 masahito_: we'll know how the push driver will end up working and can discuss with fabiog, even if the code isn't in master 00:59:42 That seems to do it for this week. 00:59:55 Thanks all! I'm looking forward to the sprint next week! 00:59:56 safe travels and see you next week 01:00:00 thanks! 01:00:04 #endmeeting