00:01:34 <thinrichs> #startmeeting CongressTeamMeeting
00:01:35 <openstack> Meeting started Thu Feb 11 00:01:34 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:36 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
00:01:38 <openstack> The meeting name has been set to 'congressteammeeting'
00:01:48 <ramineni> hi
00:02:50 <thinrichs> masahito, pballand: courtesy ping
00:02:51 <masahito> hi
00:03:06 <thinrichs> Here's my agenda for today…
00:03:23 <thinrichs> 1. Austin summit
00:03:28 <thinrichs> 2. Mitaka timelines
00:03:34 <thinrichs> 3. Distributed arch updates
00:03:36 <thinrichs> Anything else?
00:03:51 <thinrichs> bryan_att: do you have anything specific for us?
00:04:16 <bryan_att> I can give an update on testing and install on OPNFV, open issues etc
00:04:49 <thinrichs> bryan_att: Sounds good.  I'll call on you in a bit.
00:04:54 <thinrichs> #topic Austin summit
00:05:19 <thinrichs> masahito: would you like to tell us a little about the talk you proposed for Austin?
00:05:35 <masahito> yes
00:05:54 <masahito> I submitted a presentation about Congress.
00:06:25 <masahito> Congress in NFV-based Mobile Cellular Network Fault Recovery
00:06:35 <masahito> https://www.openstack.org/summit/austin-2016/vote-for-speakers/presentation/7199
00:07:26 <masahito> feel free to add +3 on it :)
00:08:29 <masahito> sorry, I have to leave here in a min. so please send me a mail if you have any question.
00:09:42 <thinrichs> masahito: thanks!  The talk looks interesting.  I'm hoping it gets accepted!
00:10:09 <thinrichs> No other announcements from me about Austin.  Questions or comments?
00:10:40 <thinrichs> #topic OPNFV update
00:10:47 <thinrichs> bryan_att: want to give us an update?
00:11:11 <bryan_att> OK, last time I gave an update was 12-17-15\
00:11:35 <bryan_att> Since then I have been focused on getting to a code freeze for the OPNFV B release, with a Congress installer support.
00:12:02 <bryan_att> I didn't make the code freeze, but I will in a service release e.g. April
00:12:34 <bryan_att> I still have the list of issues I noted in Dec to send in an email. That's my open item for this team.
00:12:50 <thinrichs> Sounds like you're getting the installer problem under control.  That's great!
00:12:57 <bryan_att> But I do have now a fairly repeatable, scripted install (bash scripts).
00:13:15 <bryan_att> I need to turn it into Ansible / Puppet etc.
00:13:46 <bryan_att> No other specific update - just I am plugging away, and developing as a user.
00:14:02 <thinrichs> Thanks for the update.  Let us know if you need anything from us.
00:14:07 <bryan_att> I will sne the issue list asap - believe me I haven't forgotten.
00:15:02 <thinrichs> bryan_att: that's much appreciated.  Thanks.
00:15:13 <thinrichs> #topic Mitaka
00:15:37 <thinrichs> The Mitaka3 deadline is coming up the first week of February.
00:15:48 <thinrichs> That means feature freeze for the server, which we're basically already in.
00:16:07 <thinrichs> It also means that the command-line client needs to be released in early Feb.
00:16:49 <thinrichs> The CLI is released earlier than the servers so every project using another project's client can iron out problems that arise when the client changes.
00:17:32 <thinrichs> The only project that I know of that's using Congress today is murano, so we may have some wiggle room there.
00:17:58 <thinrichs> But let's try to get the client in shape by Feb 1.
00:18:22 <thinrichs> In particular that means knowing whether we'll still be able to create/delete datasources.
00:18:53 <thinrichs> As long as we don't decide to pull that feature out in Mitaka, we could probably release the client today and be fine.
00:18:57 <thinrichs> Any thoughts?
00:19:47 <ramineni> thinrichs: client should wrk as is now with old architecture right
00:19:55 <thinrichs> ramineni: right
00:20:12 <thinrichs> It's only if we try to transition entirely to the new arch and we don't support create/delete datasources in the new arch.
00:20:20 <thinrichs> that the client would need to change.
00:20:42 <ramineni> thinrichs: ya
00:21:04 <thinrichs> In my mind, the plan is to keep create/delete datasources whether we're in the new arch or the old arch.
00:22:02 <ramineni> thinrichs: i think logic for add/delete datasources is in datasource manager right
00:22:02 <thinrichs> If we do that, the client will work pretty much as is.
00:22:08 <ekcs> thinrichs: do you mean Mar 1 instead of Feb 1 for client release?
00:22:09 <thinrichs> ramineni: right
00:22:23 <thinrichs> March1, not Feb1.  Right ekcs
00:22:30 <bryan_att> thinrichs: a clarification - if you can't create datasources, is there a fixed list that are always available?
00:23:00 <ramineni> thinrichs: then i think we might need more changes , as currently it doesnt touch datasource-mgr in new arch
00:23:01 <thinrichs> bryan_att: the idea was that you would control the datasources at configuration time, not at run-time.
00:23:19 <bryan_att> OK, clear.
00:23:24 <thinrichs> bryan_att: so if you wanted to restart the datasources, you'd need to restart the system.
00:23:32 <thinrichs> ramineni: right they're in the datasource manager.
00:23:41 <thinrichs> ramineni: ekcs has started moving that functionality to DSE2
00:24:10 <ramineni> thinrichs: oh, great
00:24:11 <thinrichs> The idea would be that for Mitaka, we could use DSE2 but just put everything on a single node.
00:24:35 <thinrichs> That would make creation/deletion of datasources work just like it does today.
00:24:51 <ramineni> thinrichs: ok
00:24:57 <thinrichs> Then after Mitaka, we could work on having multiple DSENodes, and creating/deleting services on each o them.
00:25:27 <thinrichs> Anyone see any problems with that plan?
00:25:43 <ramineni> thinrichs: no, sounds good
00:26:21 <thinrichs> We've naturally fallen into the next topic…
00:26:25 <thinrichs> #topic distributed arch
00:26:39 <thinrichs> There's been a lot of activity on this since last week.
00:26:50 <thinrichs> Which is great!
00:27:12 <thinrichs> I took stock of where we are earlier today.
00:27:31 <thinrichs> I went through the bug list and blueprint list and added a few bugs.
00:27:46 <thinrichs> What I'm doing now is marking all the DSE2 issues as High importance
00:28:06 <thinrichs> If it's something that we need to get done before mitaka3, I added mitaka3 as the milestone.
00:28:20 <thinrichs> If it's something that we can wait on until after Mitaka, I didn't add the mitaka3 milestone.
00:28:58 <thinrichs> Generally, we want to focus on functionality and correctness, and leave optimization and code cleanliness to later.
00:29:17 <thinrichs> Questions on any of that?
00:30:10 <thinrichs> Let's hear some status updates on what people have done, what they're stuck on if anything, and what they're hoping to do next.
00:30:25 <thinrichs> ramineni: want to start?
00:30:31 <ramineni> thinrichs: sure
00:31:26 <ramineni> thinrichs: iḿ done with migrating api models , and exceptions patch is in progress , once that done i have one more bug assigned of migrating test_congress to dse2
00:32:05 <ramineni> thinrichs: for exceptions patch, i have got all services registered on peers from control bus
00:32:38 <thinrichs> ramineni: cool!
00:33:16 <thinrichs> Are you going to add a method to DataService that encapsulates that?  Or is it not generally useful?
00:33:19 <ramineni> thinrichs: ill raise a dependent patch to enable all the tests already merged
00:33:36 <thinrichs> ramineni: sounds good
00:33:53 <thinrichs> ramineni: nice job on the api models.  Very clean.  Example…
00:34:04 <thinrichs> https://github.com/openstack/congress/blob/master/congress/api/status_model.py
00:34:36 <ramineni> thinrichs: :) thanks
00:35:10 <ramineni> thinrichs: currently we have a function in dse node to get the dse status
00:35:18 <thinrichs> I'm moving the couple of API models I worked on over to your new basecalss.
00:35:24 <ramineni> thinrichs: but that doesn include services running on current node
00:36:30 <ramineni> https://github.com/openstack/congress/blob/master/congress/dse2/control_bus.py#L127
00:36:54 <thinrichs> ramineni: I think there were several places we wanted to know if a dataservice existed, so having that functionality as part of the DSE2 makes sense, I'd say.
00:37:21 <ramineni> thinrichs: yes, but should we status of current node too, to get all the data at one place?
00:37:36 <ramineni> should we add**
00:38:04 <thinrichs> I think the operation I saw in the code was: "does service X exist"?
00:38:35 <thinrichs> But yes I would think we should have an abstraction that combines local and remote services.
00:39:11 <thinrichs> ramineni: anything else?
00:39:36 <ramineni> thinrichs: no, migrting test_congress is pending from my side
00:39:51 <thinrichs> ramineni: sounds good.
00:39:56 <thinrichs> ekcs: want to go next?
00:40:13 <ekcs> thinrichs: sure.
00:41:39 <ekcs> I made a minimal change to managers/datasource to get it working on deepsix2. I also looked at whether we can rely on migrating datasource_model instead, but i’m not I totally understand the vision.
00:43:56 <thinrichs> I think what we can do is move the creation/deletion of datasources out of the datasource manager and into the DseNode class.
00:44:26 <thinrichs> I'd think the rest of the functionality in the datasource manager is obsolete with the new API-models.
00:45:10 <ramineni> ekcs: ya, migrating to dsenode would be better
00:45:38 <thinrichs> #link https://github.com/openstack/congress/blob/master/congress/managers/datasource.py
00:45:59 <thinrichs> I'm perusing the code now…
00:46:55 <thinrichs> The other way to look at it is that if we look at the API datasource_model, we basically need to migrate that functionality into the DseNode
00:48:51 <thinrichs> After perusing, it looks like most of the functions inside the datasource manager are used for creation/deletion.
00:49:18 <thinrichs> Some definitely aren't, but most seem to be.
00:50:26 <thinrichs> ekcs: maybe your existing datasource manager migration makes sense for now.
00:50:36 <thinrichs> We'll want to move that code out of the manager and into the DSeNode eventually, but that's more cosmeetic than functional.
00:50:47 <thinrichs> ekcs: what do you think?
00:51:31 <ekcs> thinrichs: I think either way is fine. Maybe I don’t understand the implications enough to have a strong opinion either way.
00:51:43 <thinrichs> Anyone else have opinions?
00:52:17 <ramineni> thinrichs: but how do we invoke the functionalities?
00:52:33 <ramineni> thinrichs: rpc is not possible
00:53:42 <thinrichs> ramineni: for now the API could send an RPC call to the DseNode it is running in (or just have a python reference to the DseNode)
00:54:01 <thinrichs> Remember that the API will be deployed as a service inside the 1 DseNode.
00:54:23 <thinrichs> But you're right that we'll need to work that out to figure out the best way.
00:55:38 <thinrichs> 5 minutes left.
00:55:51 <ekcs> I’m not following. Will need to catch up in my understanding.
00:56:51 <thinrichs> ekcs: okay.  Let's move ahead with the migration you already did for the datasource manager.  I'll dig into it a little to see if there's anything left to do.
00:56:58 <thinrichs> #topic open discussion
00:57:00 <thinrichs> Before we run out of time, we have a newcomer.
00:57:15 <thinrichs> tsandall: could you introduce yourself?
00:57:25 <tsandall> thinrichs: thanks!
00:58:25 <tsandall> hey all, name is Torin Sandall. I started looking into congress last summer after the Vancouver summit.
00:58:40 <tsandall> I'm excited about making more contributions to congress in the future!
00:59:07 <tsandall> ...and as of recently, I'm working at Styra, Inc.
00:59:22 <tsandall> that's all for now :)
00:59:26 <ekcs> tsandall: awesomeness.
00:59:45 <ramineni> tsandall: great, welcome :)
00:59:48 <thinrichs> tsandall: Welcome (officially)!
01:00:18 <thinrichs> And we're out of time.  Let's keep pushing to hit that mitaka3 deadline!
01:00:22 <thinrichs> #endmeeting