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