00:01:56 #startmeeting congressteammeeting 00:01:57 Meeting started Thu Apr 27 00:01:56 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:58 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 00:02:00 The meeting name has been set to 'congressteammeeting' 00:02:42 Hi ekcs - on mobile heading out on vacation 00:02:46 hi all. as usual, topics are kept here: https://etherpad.openstack.org/p/congress-meeting-topics 00:02:52 Hi all 00:02:59 not a lot there right now. feel free to take a moment and add your topics =) 00:03:11 hi aimeeu ! that's great enjoy your vacation! 00:06:24 sorry, late. 00:06:40 np! topics kept here as usual. https://etherpad.openstack.org/p/congress-meeting-topics 00:07:34 ok let's get started then. 00:07:46 #topic policy library 00:08:35 We had a lively discussion last week, with many different visions of policy library. I've incorporated some of that into the spec, especially the discussion of alternatives. 00:08:41 is there anything to talk about here? 00:10:56 One thing of potential interest: 00:11:40 when creating a policy including rules 00:11:42 The policy engine rule insert code would require some careful 00:11:42 reworking to ensure policy creation with rules is transactional. That is, 00:11:42 if insertion fails at the third rule (say because of cross-policy 00:11:42 recursion), the first and second rule insertions are undone without having 00:11:42 caused any effect (triggered actions or altered query answers). 00:12:26 some care will be needed to make sure the different locks we have going on don't interfere. 00:12:38 anyway. let's move on if there isn't much to talk about now. 00:13:11 ekcs: one question 00:13:24 yup. 00:14:10 Is the implementation wrapping a transactional boundary for insertion into the DB? 00:14:33 Or is the transaction done at a higher level? 00:14:46 I guess we can't really do it at a higher-level than the DB. 00:14:58 there are two parts. 00:15:12 1 is the transactional boundary in DB, that makes sure other instances of the policy engine don't load a partially inserted policy (rules) 00:15:35 2 has nothing to do with DB. it's within the policy engine itself. 00:15:59 the current flow for inserting rule is insert into engine first. if succeed, then write to DB. 00:16:03 Sorry—reading through your 2 main things section in the spec now 00:16:44 because some of the checks for rule insertion must be done in engine. 00:18:25 Could there be a race if 2 policies are recursive? 00:18:26 PE1 loads policy1 into engine; PE2 loads policy2 into engine and into DB; PE1 (having found no recursion) writes policy1 to DB. 00:18:56 btw triggers are complicated because I think the triggers are handled on rule insertion. 00:19:03 Right 00:19:16 Is recursion the thing that's complicating everything? 00:20:15 The race issue I think is handled by DB locking already in place. 00:21:02 at the very beginning of inserting a new rule, policy engine aquires a DB lock to prevent any other changes in the mean time. then syncs to make sure in-mem state is the same as DB state before continuing. 00:22:47 So it locks the duration of the insert. Not sure how expensive that'll be. Maybe large policy inserts are infrequent. 00:22:54 recursion is one thing. but I'm not totally clear right now on all the things that may cause a rule insert to fail at the policy engine level. 00:24:33 right. basically we're saying rule inserts can have high latency. expect that. 00:24:45 won't affect query performance. 00:25:42 thinking about triggers again, I don't think we can somehow lock out the trigger activation. I think we need to write some new code that does all the policy-engine level checks for a set of rules, before inserting any of them. 00:26:07 I'll need to dig into the code some more to say for sure. 00:27:35 I remember that trigger code was tricky to get right 00:28:03 Happy to jump on a call if that helps 00:29:58 thanks. yea unfortunately the engine was never designed to handle transaction insert of a set of rules. so it may take some serious reworking to get right. 00:30:11 in fact, I realized that we have a problem even today. 00:30:32 when we delete a policy, the rules are deleted one at a time. 00:31:01 so say I have a policy with two rules: 00:31:07 good(x) :- .... 00:31:31 execute[...] :- thing(x), not good(x) 00:32:07 when the first rule is deleted but before the second rule is deleted, I think an 'false' execution can trigger. 00:32:38 will need to study the trigger code to be sure. 00:34:21 anyway should we move on? 00:35:18 Yep 00:36:14 ok then. 00:36:22 #topic PTG 00:36:45 ok not much to say here. but as mention before it's scheduled for sep 11-15 in denver. 00:36:57 we need to decide in may whether we want to hold sessions there. 00:38:15 ok then. 00:38:22 #topic open discussions 00:38:29 anything else we want to talk about? 00:39:12 hi ramineni_ 00:40:41 hi ekcs.. sorry im late .. 00:40:56 np =) 00:41:14 ekcs: so any discussion on gate issues? 00:41:21 oh right almost forgot. 00:41:26 #topic gate failure 00:42:00 so many of our tempest tests have been failing. 00:42:21 I haven't looked very deeply, but it seems like transport related issue maybe. 00:42:26 ekcs: none of the datasource service is starting actually 00:42:37 oh I see. 00:43:25 any idea why? 00:44:06 ekcs: http://logs.openstack.org/38/458038/1/check/gate-congress-dsvm-api-mysql-ubuntu-xenial/2507afe/logs/screen-congress-datasources.txt.gz 00:44:43 ekcs: i noticed while devstack patch is failing , first thought its related to my patch, then i noticed its failing on every patch 00:45:49 ekcs: not usre, if any change in keystone or somthing 00:46:15 ekcs: ill look into it more deeply today, if anyone havent looked into it yet 00:46:24 I'm a little confused. 00:47:07 oh nvm I get it. 00:47:20 ok so yea guess we'll have to figure out what changed. 00:47:47 ekcs: yes 00:48:26 let's share things we find (ML maybe?) as we go. so it may help others make progress. 00:48:55 ekcs: sure 00:50:42 anyway keystone seems like the prime suspect. Cuz they all fail with failing to connect to keystone. 00:50:43 ConnectFailure: Unable to establish connection to http://104.239.192.246:5000/v3/auth/tokens 00:51:21 ekcs: ya, not sure why, all services seem to be up 00:52:16 ramineni_, right. 00:52:18 ok anything else on gate failure or other topics? 00:54:40 ok let's wrap up a few minutes early then if there isn't more to discuss. 00:55:10 have a great week/weekend everyone! 00:55:42 thanks! 00:55:53 thanks all! 00:55:58 #endmeeting