17:00:50 <thinrichs> #startmeeting CongressTeamMeeting
17:00:51 <openstack> Meeting started Tue Jan 13 17:00:50 2015 UTC and is due to finish in 60 minutes.  The chair is thinrichs. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:52 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:56 <openstack> The meeting name has been set to 'congressteammeeting'
17:01:17 <sarob> A
17:01:23 <thinrichs> Last week I forgot to start the meeting.  Logs can be found here…
17:01:23 <sarob> Oops
17:01:31 <thinrichs> #link http://eavesdrop.openstack.org/irclogs/%23openstack-meeting-3/%23openstack-meeting-3.2015-01-06.log
17:01:45 <thinrichs> Search for "thinrichs"
17:02:13 <thinrichs> Let's get started with status updates from people who have high-priority blueprints.
17:02:28 <thinrichs> #topic status
17:02:29 <thinrichs> cloadtoa_: want to go first?
17:02:44 <arosen1> Hi
17:03:01 <thinrichs> arosen1: Hi—we're starting with status updates from people with high-priority blueprints.
17:03:12 <cloudtoa_> sure
17:04:35 <thinrichs> cloudtoa_: How's the control bus design going?
17:04:36 <cloudtoa_> The control-bus blueprint will be up today.
17:05:20 <cloudtoa_> The hierarchical DSE and table middle-ware will be up over next couple of days.
17:06:04 <cloudtoa_> These blueprints have relationships/dependencies with each other, so I needed a little time to sort that out.
17:06:14 <thinrichs> Any questions about the control-bus that you think the group should discuss as a whole?  (Stuff that might be hard to do over Gerrit comments.)
17:06:39 <thinrichs> Maybe even just a few sentences about the design?
17:06:42 <cloudtoa_> I'll summarize the blueprint...
17:08:12 <cloudtoa_> We will create a new class "data services plane" or "data services domain" and this class will contain a route table and a "collections directory."  When modules are loaded they register with the directory.  The directory will contain a list of loaded modules and their associated data collections (i.e., tables, etc).
17:09:34 <cloudtoa_> All modules subscribe to this directory automatically.  When a module subscribes to a collection, it will look for it in the directory.  When updates to the directory occur, each module will evaluate it's list of desired subscriptions against the new directory listing.
17:10:37 <cloudtoa_> This will eliminate a lot of chatter in the DSE.  This will also lend itself to multiprocess Congress when we get to that point (individual processes can share their directories).
17:11:15 <cloudtoa_> All told.
17:11:24 <thinrichs> Less chatter on the DSE should help with debugging.  So that's great!
17:11:34 <thinrichs> Moving us toward a multiprocess version of Congress is also great!
17:11:34 <alexsyip> where does the directory live?
17:12:19 <alexsyip> On the congress server ?
17:12:26 <cloudtoa_> Within the new "Data services plane" object.  This object will contain the routeTable and the directory.
17:12:31 <rajdeepd> what does a module mean in this case?
17:12:47 <cloudtoa_> A datasource driver, the policy-engine, etc.  It's a deepsix module.
17:14:40 <cloudtoa_> Alexsyip:  where we instantiate a routeTable object now, we will instantiate a "Data services plane" object instead.
17:14:59 <thinrichs> Having a single routeTable/directory is okay here because when we move to multiprocess every process is an instance of DSE, which means it has its own routeTable/directory.
17:15:04 <thinrichs> Is that right?
17:15:42 <cloudtoa_> Yes...
17:16:02 <alexsyip> So does every module have it's own copy of the directory ?
17:16:23 <cloudtoa_> Yes... but it's not a large data structure.
17:16:44 <alexsyip> Ok, I'm just curious, not saying there's a problem.
17:16:58 <alexsyip> Sounds good to me.
17:17:12 <thinrichs> Any other questions/comments about the control bus?
17:17:39 <arosen2> sounds good to me. I think the design will be more clear once we start seeing code for it as well :)
17:17:43 <thinrichs> Remember that the DSE is how the policy engine and datasource drivers communicate.
17:17:52 <rajdeepd> so route table is eventually consistent
17:18:47 <cloudtoa_> The directory is eventually consistent, the routeTable is separate.
17:19:18 <arosen2> cloudtoa_:  are we actually writing things to disk? I'm a little confused by choice of words "directory"
17:19:28 <rajdeepd> how do we make sure directory is not a single point of failure
17:20:01 <alexsyip> The directory shares fate with each module right?
17:20:06 <cloudtoa_> arosen2:  No.  I should change the wording.  It ultimately is just a table in memory.
17:20:09 <alexsyip> It's just keeping track of which other modules exist.
17:20:28 <arosen2> cloudtoa_: ah okay.
17:20:37 <alexsyip> So if the directory dies, the associated module will die also.
17:21:17 <cloudtoa_> rajdeepd: For a given set of modules talking to each other, there is a routeTable object, for instance.  If this dies, there is no routing between the modules.  the routeTable and this new "directory" will be contained together within a new "data services plane" object.  If this object dies, then you have no DSE.
17:22:25 <thinrichs> Let's wrap this up in 1 minute so we have time for everyone else.
17:22:32 <rajdeepd> i am assuming HA architecture will come later then
17:23:16 <cloudtoa_> Yes... but let's move discussion to Congress after meeting if you like.
17:23:31 <cloudtoa_> sorry the #congress chat room, I meant.
17:23:36 <thinrichs> Yep—I'd suggest we continue this on #congress after the meeting.
17:23:50 <thinrichs> (Or if it's too late for you rajdeep, maybe on the mailing list.)
17:23:57 <thinrichs> Let's move on to another blueprint.
17:24:11 <thinrichs> zhipeng: how are you doing on the policy engine triggers?
17:24:35 <rajdeepd> thinrichs : ok
17:26:10 <thinrichs> zhipeng: we'll come back to you.
17:26:34 <thinrichs> madhumohan emailed me saying he's working on adding modal operators.
17:26:55 <thinrichs> This would enable us to write things like...
17:27:29 <thinrichs> execute[disconnectNetwork(vm, net)] :- error(vm), nova:network(vm, net)
17:27:46 <thinrichs> That is, modals allow us to write nice-looking policies to do reactive enforcement.
17:27:52 <arosen2> nice
17:27:58 <thinrichs> He's currently working on the unifier.
17:28:13 <thinrichs> It's still a WIP, but I'll find the link.  One sec.
17:28:39 <thinrichs> #link https://review.openstack.org/#/c/144922/
17:30:06 <thinrichs> I also know that srangare has been working on adding aggregates (like sum/count) to the policy engine.
17:30:53 <thinrichs> This would let us write policies like "there's an error if there are at least 5 VMs with certain characteristics".
17:31:13 <thinrichs> #link https://review.openstack.org/#/c/140253/
17:32:00 <thinrichs> Another blueprint that's actively being developed is one where we're integrating Congress with Murano (an application-catalog).
17:33:07 <thinrichs> They found a limitation of the Congress client, where the URLs we're constructing are too long.
17:33:08 <thinrichs> https://bugs.launchpad.net/congress/+bug/1410080
17:33:44 <thinrichs> I haven't looked into whether this is a problem with the client or the API itself.
17:33:48 <thinrichs> Any takers?
17:33:54 <arosen2> it's a problem with the server.
17:34:01 <arosen2> I can take this one.
17:34:14 * arosen2 a problem with the api i mean
17:34:38 <thinrichs> Great!  They seem to be moving quickly, so let's do what we can to not be a blocker for them.
17:34:45 <arosen2> yup
17:35:21 <thinrichs> Overall, that project seems to be going well.  Having someone do a deep integration with Congress is exciting!
17:35:35 <thinrichs> Another blueprint: horizon-create-policies.
17:35:46 <thinrichs> jwy: How's that going?
17:35:58 <jwy> all right, started building up the framework for that
17:37:03 <thinrichs> jwy: want to briefly describe how people will be adding/deleting policy statements through horizon?
17:37:21 <jwy> sure
17:38:19 <jwy> from the page listing all the policies, there is a button to add a new policy
17:38:41 <jwy> from the policy's detail pages, where the rules would be listed, there is a button to add a new rule
17:39:12 <jwy> the interesting part will be the form for adding the rule, which is still a work in progress
17:39:24 <jwy> does that general workflow make sense
17:40:13 <thinrichs> The workflow seems good to me.
17:40:46 <thinrichs> When the user adds a new rule, do we have a text-box pop up dynamically at the end of the existing rules?  Or does a new form pop up?
17:41:26 <jwy> new form
17:41:41 <thinrichs> I could imagine the author wanting to see the other rules while writing the new one.
17:41:54 <jwy> i see
17:42:13 <jwy> ok let me think about how that could happen
17:42:51 <jwy> in general, for horizon integration, can i assume that the horizon installed in conjunction with congress will have the latest code?
17:43:09 <thinrichs> That's a good question.
17:43:31 <arosen2> i think that's a good assumption
17:43:59 <arosen2> i don't think we want to make things that complicated on ourselfs initially.
17:44:06 <thinrichs> It'd be nice to work with older instances of Horizon.
17:44:20 <thinrichs> Most customers don't run on the bleeding edge.
17:44:48 <thinrichs> But we definitely need to work on the newest version, so let's start there.
17:45:05 <arosen2> i'd guess in most cases it should work with older versions out of the box? Though I think it would be hard for us to test this without a lot of effort per say.
17:45:12 <jwy> there were some changes made in horizon in november which i had just sent a patch out for, but that would break older horizons
17:45:30 <jwy> i'll revise that patch to handle older versions then
17:45:33 <thinrichs> I see.
17:45:38 <jwy> since nov is pretty recent
17:46:20 <jwy> sorry, getting off track from blueprints!
17:46:23 <jwy> that's all i have about mine
17:46:24 <thinrichs> jwy: Do what you think is right here.  Find the balance between being backwards compatible and getting the features in place that we need.
17:46:34 <thinrichs> But this is an important discussion.
17:46:42 <jwy> ok, thanks
17:48:24 <thinrichs> Let's try this again..
17:48:27 <thinrichs> zhipeng: you around?
17:49:24 <sarob_> China time
17:50:00 <sarob_> Bp update by end of wk
17:50:05 <thinrichs> I see.
17:50:19 <sarob_> -nick sarob
17:50:31 <sarob_> \nick sarob
17:50:32 <thinrichs> zhipeng is working on policy-triggers, which are crucial for our reactive enforcement push in this cycle.
17:50:35 <sarob_> Arg
17:51:01 <arosen2> other way / sarob_ :P
17:51:14 <thinrichs> There's also the action-execution-interface, which is crucial, and I haven't heard from kitho.
17:51:20 <sarob> :)
17:51:59 <sarob> Kitho is people constrained
17:52:26 <thinrichs> A few minutes left.  Who else wants to report on status?
17:52:37 <sarob> Murano bp only right now
17:53:45 <arosen2> I'm working on a neutronv2 datasource driver. Hopefully that should be good to go soon.  Here's the spec if anyone wants to read about it: https://review.openstack.org/146928
17:54:05 <arosen2> there's also a wip patch that implemements it. Just working on adding testing now.
17:54:17 <arosen2> .....that's it.....
17:55:05 <sarob> That's it for me too
17:56:30 <thinrichs> rajdeepd: you still with us?
17:56:39 <rajdeepd> yes
17:56:40 <thinrichs> (It's really late for him in India.)
17:56:47 <rajdeepd> no updates this week
17:56:59 <rajdeepd> warming up in the new year :)
17:57:07 <thinrichs> rajdeepd: :)
17:57:15 <thinrichs> As are we all.
17:57:27 <rajdeepd> will sync with jwy
17:57:43 <thinrichs> 3 minutes left.  Anything else to bring up (and possibly continue in #congress)?
17:57:56 <thinrichs> #topic open discussion
17:59:00 <thinrichs> Okay.  Let's call it then.
17:59:15 <thinrichs> Thanks everyone!
17:59:21 <rajdeepd> thanks
17:59:21 <thinrichs> #endmeeting