17:01:09 <thinrichs> #startmeeting CongressTeamMeeting
17:01:10 <openstack> Meeting started Tue Jun 16 17:01:09 2015 UTC and is due to finish in 60 minutes.  The chair is thinrichs. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:01:13 <openstack> The meeting name has been set to 'congressteammeeting'
17:02:17 <thinrichs> We'll get started as usual with status updates.
17:02:19 <thinrichs> #topic status
17:02:27 <thinrichs> alexsyip: want to start?
17:03:30 <thinrichs> masahito: how about you?
17:03:32 <alexsyip> I was working a bit on the tempest tests, but have been working on something else for a little while.
17:03:45 <alexsyip> I want to return to working on HA this week.
17:03:47 <thinrichs> masahito: hang on—alexsyip is here
17:04:34 <thinrichs> alexsyip: that patch to get the python client into global requirements hasn't merged.
17:04:35 <thinrichs> https://review.openstack.org/#/c/190669/
17:04:45 <alexsyip> yeah I saw that.
17:04:56 <thinrichs> It got a +2 and then someone else changed the line above ours, and so there was a merge conflict.
17:05:05 <alexsyip> Are you just waiting for a code review?
17:05:33 <alexsyip> Maybe you can prod someone on IRC to do a quick review.  You need two reviews.
17:05:54 <thinrichs> Yep.  For everyone else… we were trying to get the tempest tests working, but the congress-python client wasn't getting installed.
17:06:13 <thinrichs> So we tried adding it to the requirements.txt to see if the tempest tests would start running properly in gate.
17:06:28 <alexsyip> I’m going to take a shot when we finally get the tempest test working again.
17:06:31 <thinrichs> But the client wasn't on the approved requirements list, so it failed.
17:07:14 <thinrichs> Now we're waiting on getting the client approved to the requirements list.  In the meantime we should be trying to figure out how to get the client installed with devstack properly.
17:07:40 <thinrichs> alexsyip: I'm not even sure who to ping.
17:07:46 <thinrichs> Maybe infra?
17:07:54 <thinrichs> Or is that the TC?  Anyone know?
17:07:56 <alexsyip> Yeah, I would try that IRC room first.
17:08:15 <alexsyip> infra would know who needs to review it.
17:08:16 <thinrichs> I'll work on that again today.
17:08:36 <thinrichs> #action thinrich will work on getting python-congressclient approved for general-requirements
17:09:19 <thinrichs> alexsyip: anything else?
17:09:32 <alexsyip> No, not much this week.
17:10:06 <thinrichs> masahito: want to give a status update?
17:10:11 <masahito> ok
17:10:37 <masahito> I pushed unit tests of api directory.
17:11:30 <masahito> I'll make a patch to correct nova:host datasources
17:12:04 <thinrichs> masahito: those were great tests!  Much better coverage than we previously had.
17:12:41 <masahito> The table doesn't show host information now. It only shows nova service list.
17:13:01 <thinrichs> masahito: sounds good
17:13:50 <thinrichs> masahito: need anything from us?
17:14:00 <masahito> thinrichs: thanks. I found some strange behavior in responses, so I'll also patch it.
17:14:31 <masahito> everything is now ok.
17:14:42 <thinrichs> It'd be great if you could file a bug for those so it's easy to see what problems you're fixing.
17:15:37 <thinrichs> masahito: the other thing we talked about in #congress after last week's meeting was a mid-cycle code sprint.
17:15:46 <thinrichs> masahito: want to summarize for everyone what we discussed?
17:16:49 <masahito> ok. I try it.
17:18:19 <masahito> we discussed mid-cycle code sprint which foucus to add scaling-out features to congress.
17:20:07 <masahito> first of all, I think we seems to change DSE to using RPC to get scaling feature.
17:22:06 <masahito> My idea is that we'll disscous the details of the change and write code of it in the code sprint.
17:23:10 <thinrichs> How does that sound to everyone?
17:24:40 <thinrichs> alexsyip: pballand: ping
17:25:21 <alexsyip> I’m in favor of replacing the DSE bus.
17:26:31 <thinrichs> alexsyip: I am in favor of augmenting the functionality of our message bus to work both within the process and outside the process.
17:27:01 <thinrichs> It would be good to make the bus work fast within the process, which DSE is fine at.
17:27:40 <thinrichs> But I don't care if we keep DSE itself and add inter-process messages, or we replace DSE entirely (as long as messages within the same process are fast).
17:27:50 <pballand> thinrichs: hey - sorry
17:27:57 <alexsyip> If we switch to using RPC for same-machine communication, the server will benefit by having multiple processes.
17:28:03 <pballand> I’m also in favor of replacing DSE
17:28:13 <thinrichs> alexsyip: good point
17:28:21 <alexsyip> I don’t think there’s much cost to using RPC over the shared queue in a single process.
17:28:46 <alexsyip> Using RPC will require us to manage two processes though.  Today there is just one process to manage.
17:29:20 <pballand> long-term, scaling out is the necessary path, so going RPC makes sense
17:29:34 <pballand> agree that there should be minimal overhead for in-process RPC
17:29:41 <thinrichs> Would it make sense to use RPCs to have multiple DSEs communicate?
17:30:04 <thinrichs> That is, put one DSE in one process and another DSE in another process (or on a different box), and use RPC to communicate?
17:30:29 <thinrichs> We might be able to implement that by adding a new DSE node to each of the DSEs.
17:30:49 <pballand> don’t care wheter we call it DSE, but each process needs a message bus and an broker
17:30:53 <thinrichs> Those new DSE nodes just happen to get their data over RPC/HTTP/whatever.
17:30:58 <alexsyip> splitting out every DSE process will require even more management.
17:31:25 <thinrichs> Ok.  Seems there's a lot to consider here.
17:31:29 <alexsyip> Maybe it wouldn’t be that bad.
17:31:36 <pballand> suggest we keep multiple greenthreads communicating over bus in a single process, but add broker to external processes
17:31:42 <alexsyip> One process for each driver, and one process for each policy engine.
17:31:43 <thinrichs> Is a mid-cycle sprint the right way to come to agreement and get the code written?
17:32:00 <pballand> that allows single-process runtime in the simple case
17:32:23 <pballand> thinrichs: that makes sense to me
17:34:08 <alexsyip> thinrichs: do you mean a summit?
17:34:27 <thinrichs> alexsyip: yep but in the middle of the cycle with just the Congress team
17:34:46 <alexsyip> Yes, I think we can make a decision there.
17:34:55 <thinrichs> 1-2 days where we huddle around the whiteboard, get the design ironed out, and hopefully even get the code written
17:35:19 <thinrichs> So we'll need to figure out logistics: where and when.  Let's do that via the mailing list.
17:35:48 <thinrichs> Anyone want to spearhead the logistics?
17:36:52 <masahito> for the change?
17:37:38 <thinrichs> masahito: to email the list, guage interest, figure out where and when to host it
17:38:55 <thinrichs> ok.  I'll take care of it.
17:39:12 <thinrichs> #action thinrichs will email the ML to ask about the mid-cycle code sprint
17:39:25 <thinrichs> running a bit short on time.
17:39:30 <thinrichs> pballand: status update?
17:40:34 <pballand> not much to report - one bug fix out for review
17:40:50 <pballand> have a +2, just trying to get devstack to work (again) before pushing
17:41:01 <pballand> working on API validation
17:41:16 <pballand> https://review.openstack.org/#/c/190761
17:41:22 <pballand> that’s it for me
17:41:52 <thinrichs> If anyone wants to take a look at that code, do it soon.  We'll push it in in the next day or two.
17:41:57 <thinrichs> pballand: thanks.
17:42:03 <thinrichs> I'll do a quick status update.
17:42:28 <thinrichs> I was looking at the datasource driver code and had a quick question.
17:43:23 <thinrichs> When translating an API result into tables using our translator-language, do we have the ability to pass a function that returns an ID for an object?
17:44:43 <thinrichs> I didn't see one, so I was thinking about adding it.
17:44:54 <thinrichs> Any reason not to?  alexsyip
17:45:23 <alexsyip> Does extract-fn work?
17:45:49 <thinrichs> Not sure.  Maybe I missed that.
17:46:25 <thinrichs> Does that only apply when extracting a Value?
17:47:04 <alexsyip> extract-fn operates on a single value
17:47:22 <alexsyip> So if the object is a dict, extract-fn would operate on obj[‘fieldname’]
17:47:39 <alexsyip> Do you want something that operates on obj or obj[‘fieldname’] ?
17:47:48 <thinrichs> Something that operates on obj
17:48:01 <alexsyip> Does obj also have other fields ?
17:48:07 <thinrichs> Yes
17:48:08 <alexsyip> that you want to extract ?
17:48:11 <thinrichs> Yes
17:48:25 <thinrichs> I basically want to construct the ID for the object as the combination of some of its fields.
17:48:35 <alexsyip> I don’t think extract-fn would apply then.
17:48:44 <thinrichs> That was my take too.
17:49:28 <alexsyip> It makes sense to add something else then.
17:49:40 <thinrichs> Ok.  Just wanted to make sure I wasn't missing something.
17:49:47 <thinrichs> Back to my status report.
17:50:10 <thinrichs> I'm planning to start working on look at integrating Congress with CloudFoundry.
17:50:31 <thinrichs> I have no clue what is involved with that, so it'll be exploratory for sure.
17:51:03 <thinrichs> By 'integrating' I mean integrating proactive enforcement...
17:51:22 <thinrichs> so that API calls into CloudFoundry can be gated on Congress.
17:52:20 <thinrichs> The other thing that's happening next week is a 15 minute video Congress update.
17:52:49 <thinrichs> From what I understand, all the PTLs are doing it.  We're all being scheduled.
17:53:08 <thinrichs> We're supposed to focus on the upcoming features for Liberty.
17:53:28 <thinrichs> I figured a 2 minute overview, followed by an update would be good.
17:53:48 <thinrichs> Here is the list of things that people have signed up for and that I think we should be doing.
17:54:01 <thinrichs> ◦	Reactive enforcement (protection, action-listing, more interface implementations)
17:54:01 <thinrichs> ◦	HA, performance
17:54:01 <thinrichs> ◦	Delegation (to Keystone), Cloudfoundry: https://blueprints.launchpad.net/congress
17:54:01 <thinrichs> ◦	datasource rule contribs: https://blueprints.launchpad.net/congress/+spec/datasource-rule-contributions
17:54:01 <thinrichs> ◦	oslo.messaging https://blueprints.launchpad.net/congress/+spec/integrate-oslo-messaging
17:54:46 <thinrichs> The oslo.messaging one conceptually includes our discussion about DSE earlier in the meeting.
17:55:20 <thinrichs> The datasource rule contribs blueprint is not really worth mentioning, I suppose, since it's so low-level compared to the others.
17:55:50 <thinrichs> The Delegation one is the biggest questionmark.
17:56:15 <thinrichs> Perhaps that should be called 'Integration with other systems'.
17:56:35 <thinrichs> Is there anything else we should include on the list?
17:59:55 <thinrichs> Okay, we're out of time.  If there are features missing from that list that we should highlight, let me know.
18:00:01 <thinrichs> Thanks all!
18:00:04 <thinrichs> #endmeeting