00:01:19 <ekcs> #startmeeting congressteammeeting
00:01:20 <openstack> Meeting started Thu Jul 20 00:01:19 2017 UTC and is due to finish in 60 minutes.  The chair is ekcs. Information about MeetBot at http://wiki.debian.org/MeetBot.
00:01:21 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
00:01:23 <openstack> The meeting name has been set to 'congressteammeeting'
00:01:58 <ekcs> hi all! happy wednesday/thursday!
00:02:08 <ekcs> as usual, topics are collected here: https://etherpad.openstack.org/p/congress-meeting-topics
00:02:22 <ekcs> please read/comment/add =)
00:02:35 <ramineni_> ekcs: hi
00:02:40 <ekcs> hi ramineni_ !
00:02:55 <thinrichs> Hi all
00:03:02 <ekcs> hi thinrichs !
00:03:13 <ramineni_> thinrichs: hi
00:03:28 <qiangcao> hi
00:04:04 <ekcs> hi qiangcao !
00:04:20 <qiangcao> hi ekcs!
00:04:24 <ekcs> qiangcao: not sure if we’ve connected before. sorry if I forget =p
00:04:52 <qiangcao> I’ve joined a few weeks ago.
00:05:03 <qiangcao> watching from far :)
00:05:32 <ekcs> qiangcao: Oh well great meeting you. would you like to introduce briefly introduce yourself?
00:06:21 <qiangcao> alright. I’m Qiang (Chang) Cao, based in Durham, NC.
00:06:55 <qiangcao> I’m a postdoc researcher at Duke university, especially interested in policies in the cloud.
00:07:09 <ekcs> qiangcao: oh sorry you already did introduce yourself a few weeks ago. sorry didn’t put the name together. well welcome again!
00:07:22 <qiangcao> I’ve watching and reading congress dicussion and docs for a while.
00:07:42 <qiangcao> Yeah, it’s ok.
00:08:21 <thinrichs> qiangcao: is there something specific you're working on?
00:08:28 <thinrichs> And welcome!
00:08:46 <qiangcao> I’m working on authorization in multi-domain systems.
00:09:15 <qiangcao> for example, naming, access control, etc.
00:10:00 <ekcs> cool! does multi-domain mean authority is decentralized?
00:10:43 <qiangcao> Right, we’re working on a system to do fully decentralized trust managment for authorization.
00:11:01 <ekcs> very cool!
00:11:16 <qiangcao> We are specially interested in systems across domains.
00:11:32 <qiangcao> I’ve looked at the congress docs.
00:12:13 <qiangcao> Here at duke, we also use datalog to represent security assertion and trust relationships.
00:12:55 <qiangcao> Congress is great. we should keep up the great work.
00:14:15 <qiangcao> if time is allowed today, it’ll be great if you can talk about the multi-tenancy in congress.
00:15:36 <ekcs> Great! Would definitely love to connect more on common interests and hear any feedback you may have for congress. Always eager for feedback from a new perspective.
00:15:42 <thinrichs> +1
00:15:51 <ekcs> ok well let’s move along then.
00:16:20 <ekcs> adminitrative stuff to get through =p
00:16:25 <ekcs> #topic announcements
00:16:49 <ekcs> as annouced before, PTG is coming up in sep.
00:16:53 <ekcs> PTG
00:16:53 <ekcs> https://www.openstack.org/ptg/
00:16:54 <ekcs> Monday - Friday, September 11-15, 2017
00:16:55 <ekcs> Congress sessions: Wed-Thu
00:17:29 <ekcs> Now is a good time to make travel plans if you plan to be there. We’re also going to do our best to get a good way for remote participants to join.
00:18:13 <ekcs> PTL nomination opens 7/31
00:18:13 <ekcs> #link https://governance.openstack.org/election/#ptl-details
00:18:49 <ekcs> if you’re interested in running for PTL I’d be happy to give more info. I’m sure thinrichs would too.
00:19:03 <ekcs> any other announcements before we move on?
00:20:17 <ekcs> ok moving on then.
00:20:19 <ekcs> #topic congress client final release
00:20:32 <ekcs> final release is due next week.
00:20:43 <ekcs> Here are the open patches: https://review.openstack.org/#/q/project:openstack/python-congressclient+status:open
00:21:18 <ekcs> hopefully we can merge them very soon and use the rest of the time for testing.
00:22:23 <ekcs> and of course if there’s anything else that needs to go into the pike release for congress client please do bring it up =)
00:22:57 <ekcs> On this patch: https://review.openstack.org/#/c/483132/
00:23:18 <thinrichs> Looks like both those have gone thru several rounds of review.  Doesn't seem like there are any blockers.
00:23:42 <ekcs> the main discussion seems to be whether we’re okay with the client command not supporting multiple YAML docs per file.
00:24:41 <thinrichs> Either way seems fine to me.
00:25:13 <thinrichs> I think for the use case we're targeting, the file would always have 1
00:25:15 <thinrichs> right?
00:25:41 <ramineni_> ekcs: seems fine ..just got confused ..why server supporting and client doesn't support ..
00:26:07 <thinrichs> If server supports N, it seems simple enough to hand over the N to the server.
00:26:42 <thinrichs> Is the client code any different to handle N?
00:27:12 <ekcs> policy library service will accept a file with multiple policies and write it to DB as multiple rows.
00:27:15 <thinrichs> Oh I see—it would take N calls to create_policy
00:27:21 <ekcs> yes exactly.
00:27:40 <ekcs> shouldn’t be too hard I just haven’t had time to think through how best to do that interaction on client.
00:28:00 <ramineni_> Why Not calls to create policy
00:28:09 <thinrichs> Simplest code would be just: for body in policies: client.create_policy(body)
00:28:14 <ramineni_> Why N calls
00:28:47 <ekcs> because each call to agnostic:create_policy creates one policy.
00:29:39 <ekcs> it’s not difficult I’m sure just a matter of figuring out how to pack up all the outputs from each call and give back to openstack client the way it expects.
00:30:45 <thinrichs> How does the server API call handle N policies?  Did we add one?  I thought we just modified the 1 API call to accept (optionally) a list of rules as a field.
00:30:58 <thinrichs> Do we have a server-side API call where you can stuff in N policies?
00:31:50 <ekcs> thinrichs: no there is no API call for creating N policies.
00:32:12 <thinrichs> Then it seems the client shouldn't permit it.
00:32:53 <ekcs> the only thing is when server loads files to library at startup, it’ll make N calls to load N policies in a single yaml file. I could just as well disable that too. But it doesn’t seem to hurt.
00:33:15 <thinrichs> I wouldn't disable it.
00:33:42 <ramineni_> ekcs: seems fine ..I'll update my vote
00:34:06 <thinrichs> The downside to putting N API calls into a single client call is that if the 5th one fails, the client isn't going to roll-back the first 4 that succeeded.
00:35:01 <thinrichs> A server-script that we use to load stuff into Congress at startup is different.  We know what we're doing.
00:35:25 <thinrichs> (BTW, I've got to leave in 10min)
00:35:27 <ekcs> thinrichs, ramineni_ ok.
00:35:53 <ekcs> ok yea taking a fair bit of time on a small issue here but need to get it done for deadline.
00:35:57 <ekcs> let’s move on then?
00:37:22 <ekcs> qiangcao: are you still around?
00:37:26 <qiangcao> yes.
00:37:34 <ekcs> we could talk more about multi tenancy now while thinrichs is here.
00:37:44 <ekcs> the rest of the topics are not super urgent.
00:37:49 <qiangcao> great.
00:37:52 <ekcs> #topic multi-tenancy
00:39:15 <qiangcao> I read through the doc. It uses statements from nova, neutron, idap, etc.
00:39:48 <ekcs> So I’m not too familiar with the efforts for multi-tenancy in congress. But some people have thought about it and sketched out working toward it i think.
00:39:59 <ekcs> qiangcao:  yup.
00:40:14 <qiangcao> can we also take statements/assertions made by tenents for policy compliance or enforcement?
00:40:35 <thinrichs> qiangcao: we don't have multiple tenants today.
00:40:40 <thinrichs> But we do have multiple policies
00:40:47 <thinrichs> So you could have alice write policyA
00:40:52 <thinrichs> and bob write policyB
00:40:56 <thinrichs> and admin write policyC
00:41:19 <thinrichs> (That's not true multi-tenancy b/c alice can see/change all of policyA, policyB, and policyC)
00:41:35 <thinrichs> Then admin's policyC can reference alice's policyA and bob's policyB
00:41:48 <thinrichs> Syntax is basically the same…
00:42:11 <thinrichs> policyC:   error(x) :- policyA:error(x), policyB:error(x)
00:42:26 <thinrichs> (Where I've chosen 'error' here arbitrarily.)
00:42:36 <qiangcao> right. so we’ll going to make separate tables to store the statements by tenants?
00:42:49 <thinrichs> Yes.
00:43:03 <thinrichs> And each tenant could have a collection of tables that they write (all the tables defined in their policy).
00:43:51 <qiangcao> how can we refer to a policy?
00:44:01 <thinrichs> Same way you refer to nova/neutron
00:44:04 <qiangcao> should the policy name be globally unique?
00:44:06 <thinrichs> Example is above
00:44:19 <thinrichs> Yes—all policy names are globally unique
00:44:23 <thinrichs> No hierarchy for policy names
00:44:36 <thinrichs> In fact, the datasource names and the policy names must all be (jointly) unique
00:44:55 <thinrichs> Meaning you can't name a datasource the same as a policy
00:45:09 <thinrichs> And you can't name 2 pollicies the same thing.  And you can't name 2 datasources the same thing.
00:45:47 <qiangcao> yeah, then Alice, Bob, and Cindy need to coordinate on names?
00:46:18 <thinrichs> Yep—that's why we don't have true multitenancy yet
00:46:26 <qiangcao> I see.
00:46:33 <thinrichs> (One of the reasons anyway)
00:46:44 <ekcs> so from what I’m hearng so far here are a few gaps to multi-tenancy.
00:46:47 <ekcs> a. globally unique policy name
00:46:48 <ekcs> b. all users can see/edit policies
00:46:49 <ekcs> c. all user policies can refer to all state
00:46:54 <ekcs> c) may be addressable by query rewriting techniques
00:47:06 <ekcs> b) can be addressed by ownership.
00:47:15 <ekcs> any other big gaps?
00:47:28 <qiangcao> how about the efficiency?
00:47:49 <qiangcao> if the alice makes a lot of policies about many things?
00:48:10 <thinrichs> Many policies doesn't make the evaluation any slower
00:48:16 <qiangcao> in your terminology, policy alice includes a lot of statements/assertions
00:48:47 <masahito> hi, so sorry to be late...
00:48:54 <ekcs> hi masahito
00:48:55 <thinrichs> Oh—right if there are many statements then that will impact performance for sure.
00:49:05 <thinrichs> Just like a database or really any system.
00:49:08 <qiangcao> for exmple, nova makes assertions for every vm.
00:49:49 <ekcs> we’ve done some benchmarks on how far we can push, but I don’t think we’ve been very comprehensive about it so far.
00:49:54 <thinrichs> Performance depends entirely on the structure of the policy.
00:50:26 <ekcs> qiangcao: are you wondering more about scalability or isolation/security/dos right now?
00:50:27 <qiangcao> yeah, it depends on the size of the inference context.
00:50:29 <thinrichs> If you write a policy that requires analyzing every VM, and every network connection to every VM, and every pair of VMs connected via the network, and all the storage devices connected to any of those VMs (for example), then it'll take a while to evaluate
00:50:56 <qiangcao> by a inference context, I mean the set of statements one need to consider for making a decision.
00:51:04 <thinrichs> Size of the data and size/complexity of the rules gives you performance.
00:51:10 <thinrichs> Right—inference context
00:51:40 <thinrichs> We're using standard datalog, so all the performance characteristics are the usual ones.
00:51:53 <thinrichs> We do top-down evaluation today without caching.
00:51:57 <qiangcao> yeah, here we’re exploring a way to make the inference context compact, only including all relevant statements.
00:51:58 <thinrichs> No recursion
00:52:28 <thinrichs> If you wanted to experiment with performance within Congress, that'd be great!
00:52:53 <qiangcao> I’ll definitly looks into that.
00:52:57 <thinrichs> There are a few performance benchmarks in the test suite
00:53:09 <thinrichs> There's a blogpost too.
00:53:21 <qiangcao> can you send me a point?
00:53:27 <qiangcao> *pointer
00:53:33 <thinrichs> http://ruleyourcloud.com/2015/03/12/scaling-up-congress.html
00:53:53 <thinrichs> Got to run
00:54:09 <ekcs> see you thinrichs
00:54:11 <thinrichs> Feel free to send email to the openstack-dev mailing list.  Just include [Congress] in the subject line
00:54:12 <qiangcao> thanks
00:54:18 <thinrichs> Talk to you all later!
00:54:25 <qiangcao> sure, ttyl
00:54:57 <ekcs> ok let’s go to open discussion for the last few minutes then.
00:55:02 <ekcs> #topic open discussion
00:55:17 <ekcs> feel free to jump in with anything.
00:55:32 <ekcs> just wanna also mention it’s feature freeze for congress server and dashboard next week.
00:55:55 <ekcs> server: #link https://review.openstack.org/#/q/project:openstack/congress+status:open+branch:master
00:55:56 <ekcs> dashboard: #link https://review.openstack.org/#/q/project:openstack/congress-dashboard+status:open
00:56:05 <ekcs> I think most of the dashboard patches are ready.
00:56:16 <ekcs> server too.
00:58:24 <ekcs> last two minutes if anyone’s got something to say =p
01:00:02 <ekcs> alright then! fun discussions today. see you all next time!
01:00:15 <ekcs> #endmeeting