00:01:11 <thinrichs> #startmeeting CongressTeamMeeting
00:01:12 <openstack> Meeting started Thu Mar  3 00:01:11 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:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
00:01:16 <openstack> The meeting name has been set to 'congressteammeeting'
00:01:24 <ramineni1> hi
00:01:35 <thinrichs> ekcs, pballand, masahito: courtesy ping
00:01:56 <thinrichs> ramineni1: hi
00:03:01 <thinrichs> masahito: are you here?
00:03:33 <thinrichs> The main thing on today's agenda is mitaka3
00:03:52 <thinrichs> Masahito sent a note to openstack-dev saying he tested the client.
00:04:02 <thinrichs> And all looked good except for 2 issues.
00:04:25 <thinrichs> #link http://lists.openstack.org/pipermail/openstack-dev/2016-March/088045.html
00:05:12 <thinrichs> Issue 1 I think we ignore.
00:05:18 <thinrichs> It says that the output of rule list isn't a table.
00:05:40 <thinrichs> We tried outputting rules as a table for a while, and it became really hard to read with any reasonably long rules.
00:05:45 <ramineni1> thinrichs: ya, i remember that output was intetional right
00:05:52 <thinrichs> ramineni1: yep
00:06:26 <thinrichs> Issue 2 is pretty minor: that the help message says you need to provide a datasource NAME
00:06:35 <thinrichs> when in reality you can provide a NAME or ID.
00:06:44 <thinrichs> #link https://bugs.launchpad.net/python-congressclient/+bug/1552212
00:06:45 <openstack> Launchpad bug 1552212 in python-congressclient "Non accurate help messages for dataosurce CLI" [Undecided,New]
00:07:00 <thinrichs> Anyone know how easy that is to fix?
00:07:11 <ramineni1> its easy
00:07:22 <ramineni1> just help message should be updated right
00:07:53 <thinrichs> That's what the bug says.
00:08:11 <ramineni1> ill check, it should be one line fix
00:08:24 <thinrichs> If it's that easy, let's go ahead and do it.
00:08:54 <ramineni1> thinrichs: ok
00:09:15 <thinrichs> I did some testing of the client as well.
00:09:19 <thinrichs> I ran into 500 errors during datasource creation ...
00:09:37 <thinrichs> #link https://bugs.launchpad.net/congress/+bug/1552037
00:09:38 <openstack> Launchpad bug 1552037 in congress "500 when creating a datasource without config" [Critical,New]
00:09:44 <ramineni1> thinrichs: oh , with datasource api model in place?
00:09:58 <thinrichs> but then realized that at the time the datasource api model wasn't moved over to dse2.
00:10:10 <thinrichs> Now that the new datasource api model has merged...
00:10:15 <thinrichs> I'll need to test it again.
00:10:58 <ramineni1> thinrichs: ok
00:10:59 <thinrichs> But otherwise I found no issues with the client.
00:11:11 <ekcs> hmmm. wonder why moving to dse2 matters here. i’ll try to reproduce.
00:11:45 <thinrichs> So once we get this quick fix into the client, I'll create the mitaka release.
00:11:54 <thinrichs> (the release for the client)
00:12:50 <thinrichs> ekcs: Not sure  But we definitely have new code to test now that we've moved over to Dse2.
00:13:19 <ramineni1> thinrichs: planning to release today your time?
00:13:21 <thinrichs> So make sure that we're testing all the current code.  No need to debug old code.
00:13:42 <thinrichs> ramineni1: I'll release tomorrow.  Too late today if something goes wrong.
00:13:58 <thinrichs> #topic server
00:13:59 <ramineni1> thinrichs: oohok
00:14:33 <thinrichs> masahito: hi!
00:14:36 <masahito> hi
00:14:38 <thinrichs> We just finished discussing the client.
00:14:39 <masahito> sorry, late
00:14:46 <thinrichs> And your analysis of the client readiness for release.
00:14:51 <thinrichs> masahito: no problem
00:15:25 <thinrichs> We decided to leave the first issue (rules not printed as a table) as it is, but to fix the second issue (incorrect help messages).
00:15:28 <thinrichs> How does that sound?
00:16:03 <thinrichs> A long time ago, we had rules printed out in a table, and they became almost impossible to read when they were long.
00:16:03 <masahito> sounds good.
00:16:52 <thinrichs> I'm planning to release the client tomorrow (my time), which gives ramineni a chance to put the fix in place.
00:17:02 <masahito> got it.
00:17:07 <thinrichs> ramineni1: you volunteered for that, right?
00:17:19 <thinrichs> Or did I just volunteer you accidentally?  :)
00:17:39 <ramineni1> thinrichs: ya, i can fix that
00:17:49 <thinrichs> Now onto the server.
00:17:59 <thinrichs> Looking at the outstanding changes…
00:18:09 <thinrichs> #link https://review.openstack.org/#/q/project:openstack/congress+status:open
00:18:49 <thinrichs> I think we just want to get Eric's top 2 changes in before we freeze master.
00:19:45 <thinrichs> ekcs: any questions that we should discuss now so we can get those merged?
00:20:11 <ekcs> thinrichs: not really. if the patches look good then pls merge. one issue:
00:20:48 <ekcs> once partitioning patch is merged, I’d like to update the heartbeat patch again to use the new partitioning convention and then merge.
00:21:19 <thinrichs> Can you push the partitioning patch ahead of the heartbeat patch?  Or would that be nontrivial?
00:21:20 <ramineni1> ekcs: one question
00:21:37 <ekcs> any order works.
00:21:54 <ekcs> no dependency as it stands.
00:22:02 <ramineni1> ekcs: we have published_tables and subscribed tables in dataserviceinfo class right? are they updated anywhere?
00:23:05 <ramineni1> ekcs: https://github.com/openstack/congress/blob/master/congress/dse2/data_service.py#L39
00:24:32 <ekcs> ramineni1: I think they’re not currently being updated. All the code is referring to DseNode for that information.
00:25:01 <ekcs> Not sure which way to make it in the future.
00:25:49 <ramineni1> ekcs: hmm,i feel  its good to have them updated , to have the info in dataservice class itself is easy to maintian right away? but if not now, may be in the future
00:26:40 <thinrichs> ramineni1: is that what you're asking in this comment in the heartbeat change?
00:26:41 <thinrichs> https://review.openstack.org/#/c/281586/10/congress/dse2/data_service.py
00:26:56 <ramineni1> thinrichs: ya
00:27:50 <thinrichs> ramineni1: sounds like that's something that's not a blocker for the patch then.  Is that patch good to merge as is?
00:28:05 <ramineni1> i feel having all the data in node makes it hard to maintain in future,
00:28:32 <ramineni1> thinrichs: ya, should be fine as is now, but may be in future if we could maintain, it would make things easier i felt
00:29:32 <thinrichs> ramineni1: got it
00:30:18 <thinrichs> I see so right now we're storing ALL subscription info inside the node, and you're suggesting we have it stored in the individual data services.
00:30:44 <thinrichs> And then on each heartbeat, we pull that data all together from the services and send it along.
00:30:49 <ramineni1> thinrichs: yes,
00:30:49 <thinrichs> That right?
00:31:40 <ramineni1> thinrichs: along with services that data is also received by default
00:31:53 <thinrichs> I guess the downside is that it'll cost a bit to assemble all the subscription info from different places on each heartbeat.
00:32:02 <ramineni1> thinrichs: so we need to extract and update
00:32:09 <thinrichs> Right.
00:32:20 <ekcs> I see the appeal in that, because each node “owns” it’s on subscriptions. On the other hand, the node is the entity that actually uses the data. the individual dataservices really dont.
00:32:41 <ekcs> s/each node/each dataservice
00:33:07 <thinrichs> Is this a question of taste/style, or is there a technical benefit to storing the subscriptions in the data services?
00:33:47 <ramineni1> thinrichs: i guess it wont be that hard to store assemble also, if we go by this approach , it should be easier than what we do now?
00:33:56 <ramineni1> ekcs?
00:34:50 <ekcs> I see it more as style. Heartbeat aside, the node is responsible for distributing incoming pubs to each service. So it’s the entity that needs the subscription information. the individuall services mostly don’t care.
00:36:06 <ekcs> storing with service has the advantage that it’s organized in a way that corresponds to the intuition that each service owns its subscription info.
00:36:23 <thinrichs> ramineni1: is there a technical benefit that you see?
00:36:24 <ekcs> but storing with node actually makes the code simpler.
00:36:54 <ramineni1> ekcs: i felt the other way
00:38:05 <ramineni1> thinrichs: its easy to maintain and understand i felt ,
00:38:17 <ramineni1> thinrichs: may be we can ignore for now
00:38:56 <thinrichs> I see both sides, and in those cases I typically think that the person writing the code should make the call.
00:39:14 <thinrichs> So let's move on.
00:39:34 <thinrichs> Sounds like the existing heartbeat patch is ready to go in.
00:40:15 <thinrichs> Maybe we merge that one and the partitioning one...
00:40:29 <thinrichs> and then you can push your test change for the heartbeat code as a separate patch ekcs.
00:40:34 <ekcs> except that it still usses old style partitioning code. so if we merge the test partition patch first then I can update hb.
00:40:42 <ekcs> oh ok that works too.
00:41:19 <thinrichs> Let's all take a look at the newest partitioning test code…
00:41:21 <thinrichs> #link https://review.openstack.org/#/c/286961/
00:41:30 <thinrichs> Eric's pushed an update recently.
00:42:00 <thinrichs> Once the existing heartbeat patch goes in, we can all start testing heavily.
00:42:10 <thinrichs> Looking for bugs and corner cases.
00:42:23 <thinrichs> Before I forget, we should update the standalone install instructions.
00:42:30 <thinrichs> Or at least make sure that they are working.
00:42:38 <thinrichs> I've got a patch to update the devstack install instructions.
00:42:46 <thinrichs> Does anyone want to volunteer to test the standalone install?
00:43:26 <ramineni1> devstack?
00:43:32 <thinrichs> Not with devstack.
00:43:36 <ramineni1> oohok
00:43:49 <thinrichs> The standalone instructions are for when you want to install just congress, without keystone, nova, etc.
00:44:17 <ramineni1> i never tried that, i can try once
00:44:31 <thinrichs> ramineni1: thanks!
00:44:51 <ekcs> i think i’ve done it before, but don’t remember whither i’ve ever gotten it completely working.
00:45:46 <thinrichs> If it doesn't actually work, we should know that.
00:46:21 <thinrichs> Otherwise, let's all spend time hammering on Congress to find as many bugs as we can and fix them.
00:46:49 <thinrichs> Once we think we've got most of the bugs squashed, we'll branch and create a release candidate.
00:47:05 <thinrichs> I'll release mitaka3 tomorrow with whatever is in master.
00:47:18 <thinrichs> Any questions?
00:48:45 <thinrichs> #topic new core
00:48:54 <thinrichs> Last topic for the day.
00:48:57 <thinrichs> A happy one.
00:49:18 <thinrichs> masahito has now officially been promoted to core.
00:49:41 <thinrichs> So you'll undoubtedly start seeing him +2 and merge code.
00:49:42 <ekcs> awesomeness
00:49:50 <thinrichs> masahito: Congratulations!
00:49:54 <ramineni1> masahito: congrats :)
00:49:57 <masahito> Thank you everyone.
00:50:55 <thinrichs> That's it on the agenda for me.  Anything else to discuss?
00:51:05 <masahito> All your support helped me. I'm really appreciating it.
00:51:55 <thinrichs> masahito: you earned it.  We're glad to have you on the team!
00:53:39 <thinrichs> Thanks all!  Have a good week.
00:53:41 <thinrichs> #endmeeting