02:32:15 <ekcs> #startmeeting congressteammeeting
02:32:16 <openstack> Meeting started Fri Apr 20 02:32:15 2018 UTC and is due to finish in 60 minutes.  The chair is ekcs. Information about MeetBot at http://wiki.debian.org/MeetBot.
02:32:17 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
02:32:19 <openstack> The meeting name has been set to 'congressteammeeting'
02:32:31 <masahito> hi
02:32:37 <ekcs> hi masahito !
02:32:47 <ekcs> how’s it been?
02:32:56 <masahito> going well
02:33:07 <ekcs> great!
02:33:48 <ekcs> hi all topics are here as usual. feel free to add yours! https://etherpad.openstack.org/p/congress-meeting-topics
02:34:04 <ekcs> Not many topics today so far.
02:35:13 <ekcs> first is just a quick announcement that Rocky-1 is this week and we tagged congress-server and congress-dashboard today.
02:35:30 <ekcs> no substantive patches in congress-client yet to require new release.
02:37:58 <ekcs> #topic additional policy engines
02:38:56 <ekcs> Since we don’t have much to talk about today I figure I’ll give an early report on something I’m working on.
02:39:51 <ekcs> from the beginning congress was architected to support multiple policy engines. hence the name “agnostic” of the main engine meaning something like the basic policy engine.
02:40:44 <ekcs> but so far we have not really created additional policy engines in a big way. we did have the experimental VM placement policy engine.
02:42:51 <ekcs> I’ve been thinking for quite a while now about wanting to support additional policy engines because 1. the performance of agnostic is necessarily limited by a) python and b) lack of specialized database optimization.
02:44:48 <ekcs> and 2. different language and formalism may be preferred/needed for users. for example, agnostic doesn’t currently support aggregates. having a SQL based policy engine would take care of that. another thing that’s come up is the lack of support for nested data like JSON. some SQL databases also have good support for that.
02:45:16 <ekcs> still it was never high enough priority to undertake a pretty major effort like this.
02:46:00 <ekcs> but pierre at orange had some networking route analysis use cases that required greater expressiveness as well as performance than the standard agnostic had. and he’s looking to integrate a z3-prover based policy engine.
02:46:25 <ekcs> so we finally have more impetus to do it.
02:47:01 <masahito> sounds nice.
02:47:20 <ekcs> basic idea is that different policy engines can use different formalisms as long as they can communicate with each other through the tables formalism provided by DSE.
02:47:52 <masahito> Which limit is the reason pierre introduced new engine?
02:48:50 <ekcs> both expressiveness and performance. on expressiveness they need recursion to compute routes. like if a is connected to b and b is connected to c and c is connected to ….  z, then a is connected to z.
02:50:15 <ekcs> also because there are many many routes in a data center computing properties and security on all of them takes a long time. I don’t know the details but he said even on the much faster z3 prover it takes a long time like maybe 1hr.
02:50:39 <masahito> got it
02:51:42 <ekcs> here’s an example: https://github.com/Orange-OpenSource/octant/blob/master/examples/routing/routing.dtl
02:52:20 <ekcs> that’s the project he already created to do it independently of congress.
02:53:32 <ekcs> anyway so the main difficulity we’ve run into is that congress data tables are not well-typed, whereas most performant engines (z3, sql, etc.) require explicit column types. so that’s something I’ve been working on.
02:54:06 <ekcs> that’s all just an report. took a littel longer than expected =p
02:54:32 <ekcs> definitely eager to hear thoughts or ideas if it jogs anything
02:55:49 <ekcs> anyway that’s all I have today. anything else to discuss? if not we can call it and talk next week =)
02:59:02 <ekcs> ok then let’s call it for today. thanks and see you next week!
02:59:06 <ekcs> #endmeeting