00:02:52 <ekcs> #startmeeting congressteammeeting
00:02:53 <openstack> Meeting started Thu May  4 00:02:52 2017 UTC and is due to finish in 60 minutes.  The chair is ekcs. Information about MeetBot at http://wiki.debian.org/MeetBot.
00:02:54 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
00:02:56 <openstack> The meeting name has been set to 'congressteammeeting'
00:03:37 <ekcs> Hi all! welcome back for another week. topics are here as usual: #link: https://etherpad.openstack.org/p/congress-meeting-topics
00:03:50 <ramineni_> hi
00:04:55 <ekcs> hi ramineni_ !
00:07:42 <ekcs> pretty quiet today haha. well lets get started
00:07:52 <ekcs> #topic gate failure
00:08:17 <ekcs> seems like we have a new kind of gate failure.
00:08:18 <ekcs> devstack@congress-api.service: Service lacks both ExecStart= and ExecStop= setting. Refusing.
00:08:46 <ramineni_> ekcs: yes, that issue is solved by this patch https://review.openstack.org/#/c/461623/
00:08:47 <patchbot> patch 461623 - congress - [Testing] Gate Issue
00:09:09 <ekcs> ah great!
00:09:36 <ekcs> ahd it seems to solve smoe of the auth problems too?
00:09:53 <ramineni_> ekcs: yes, but the problem is with oly keytsonev2
00:10:03 <ekcs> i’ve tried to look for devstack and keystone changes merged around the right time to see where the auth problem came from, but haven’t found something exact.
00:10:06 <ekcs> oh perfect!
00:10:25 <ekcs> so maybe we just need to move all the drivers to keystone v3?
00:10:26 <ramineni_> ekcs: as you mentioned it is because of the change in endpoint of keystone
00:11:19 <ramineni_> ekcs: but the problem is we have keystone_driver.py which is v2 one, should we deprecate it? all the tests related to that driver is failing
00:12:19 <ekcs> hmmm. we shoudl probably figure out why v2 is failing, and whether it’s supposed to fail or not.
00:12:28 <ekcs> do you know if v2 is not supported any more?
00:12:33 <ramineni_> ekcs: and also i need to check if they have totally deprecated v2
00:12:59 <ramineni_> ekcs: i knw its deprecated , but totally removed or not, i need to check
00:14:48 <ekcs> I see. Great. if they have removed keystone v2, I’d think we also removed keystone v2 driver. or just document that it doesn’t work with latest openstack version, and remove the tempest tests for that driver.
00:14:56 <ekcs> does that make sense?
00:15:28 <ramineni_> ekcs: sounds good, ill look into that today
00:17:26 <ekcs> according to this (probably out of date) document, v2 shoud be around in pike. well i guess looking at keystone patches is the place.
00:17:34 <ekcs> anyway great work figuring this out!
00:17:51 <ekcs> anything to discuss right now on gate issue?
00:18:17 <ramineni_> ekcs: no
00:18:37 <ekcs> ok next topic then.
00:19:08 <ekcs> #topic policy library
00:19:49 <ekcs> spec under discussion: https://review.openstack.org/#/c/457880/
00:19:50 <patchbot> patch 457880 - congress-specs - policy library spec
00:20:02 <ekcs> there are a few TODO sections but those are very minor. the spec is ready for review.
00:20:40 <ekcs> also have a patch up for review that implements one of the key functions needed by the spec: #link https://review.openstack.org/#/c/460348/
00:20:41 <patchbot> patch 460348 - congress - support transactional insert of multiple rules
00:21:01 <ekcs> anything to discuss here?
00:22:42 <ramineni_> ekcs: ok, ill get to the spec this week
00:23:07 <ekcs> I’ll point out one interesting thing. also noted on gerrit. it’s always been the case that if insert rule into policy engine succeeds, then later write to db fails, the rule may have already have effects (triggers, query answers), before the insert is undone.
00:23:37 <ekcs> itd be pretty hard to change that behavior. but we shoudl still think about whether that’s acceptable or not.
00:24:10 <ekcs> cool thanks!
00:24:14 <ekcs> let’s move on then.
00:24:29 <ekcs> #topic patches
00:24:32 <ramineni_> ekcs: so, if inmem one suceeds and db one doesnt , then the problme is seen you are saying right?
00:24:33 <ekcs> any patches to discuss?
00:24:52 <ekcs> ramineni_: right.
00:25:03 <ramineni_> ekcs: cant we reverse the insertion
00:25:04 <ramineni_> ?
00:25:29 <ramineni_> ekcs: insert only if DB one suceeds
00:26:09 <ekcs> that’s how policy creation is done. that would make more sense, but for rules, there are checks that need to be done that can’t be done in db
00:26:26 <ekcs> so whoever did the DB code initially decided to insert into engine first.
00:27:27 <ekcs> and in order to reverse that, we’d need to impelement kind of a separate policy engine that checks the rules are ok to insert, then insert into DB, then insert into actual policy engine.
00:28:01 <ramineni_> ekcs: i thought policy synchronizer takes care of inmem for policy insertion
00:28:09 <ekcs> the main problem is that policy rule checks are complex (recursion and stuff), unlike policy which just need to not have the same name as existing
00:28:18 <ramineni_> ekcs: ya, rules one looks difficult
00:28:39 <ramineni_> ekcs: ok, got it
00:28:45 <ekcs> hmmmm actually.
00:28:59 <ekcs> if we insert into DB first, that may work.
00:29:24 <ekcs> other strange things happen, but maybe ok.
00:29:41 <ramineni_> ekcs: ya, but not usre if it is possible
00:29:55 <ekcs> insert into DB, then synchronizer needs to tolerate failing to insert into policy engine.
00:30:02 <ekcs> which is not hard.
00:30:29 <ekcs> but if someone in the mean time lists rules, the disallowed rule would be listed because it’s according to DB.
00:30:37 <ekcs> but maybe that’s ok.
00:30:48 <ekcs> insert into DB, insert into PE, then undo from DB if PE fails.
00:31:23 <ramineni_> ekcs: right, if we have rule enable/disable option that might solve the problme you are saying
00:31:39 <ramineni_> ekcs: we can mark it disabled first and enable once all checks pass
00:31:54 <ramineni_> ekcs: but i think that is the second stage
00:32:11 <ekcs> hmm. something like that. marking the rule as provisional / disabled.
00:33:13 <ramineni_> ekcs: ya, enable/disable also good thing to add , i think bryan also suggested the same during PTG
00:33:57 <ekcs> may be good thing to add. but I think we can use the disbaled concept for this problem, witout exposing that to user.
00:34:16 <ramineni_> ekcs: yes, right
00:34:36 <ekcs> ok well. good discussion.
00:34:49 <ekcs> anything more?
00:34:59 <ekcs> policy library or other patches? or anything else.
00:35:22 <ramineni_> ekcs: no
00:35:49 <ekcs> haha ok then. should we end meeting ?
00:36:10 <ramineni_> ekcs: next meeting would be cancelled rigt?
00:36:25 <ramineni_> ekcs: everyone will be at summit?
00:36:45 <ekcs> i was thinking about that. OS summit is next seek. masahito, aimeeu and me will all be there. you?
00:37:04 <ramineni_> ekcs: no, not making it this time
00:37:15 <ekcs> I dont know if thinrichs is going. so I was debating whether to have meeting anyway.
00:37:28 <ekcs> since it maybe like half the people there and half not.
00:37:33 <ekcs> I can still hold a meeting.
00:37:52 <ramineni_> ekcs: ya, ok
00:38:10 <ekcs> well maybe let’s decide over ML later.
00:38:24 <ramineni_> ekcs: sure,
00:38:57 <ekcs> i’m leaning toward having a meeting. even if a couple people cant make it. do you have opinion?
00:39:40 <ramineni_> ekcs: ya, you should hold the meeting , disucusing problems in person would be resolved faster :)
00:40:05 <ekcs> Oh you mean in person meeting.
00:40:12 <ekcs> I meant IRC meeting.
00:40:27 <ramineni_> ekcs: oh , :)
00:40:33 <ramineni_> ekcs: im ok with that too
00:41:00 <ramineni_> ekcs: if you guys are not tired at summit , then may be we can have
00:41:10 <ekcs> ok. well let’s decide later.
00:41:24 <ekcs> anything else to talk about?
00:41:42 <ramineni_> ekcs: no
00:43:35 <ekcs> alright. later then!
00:43:39 <ekcs> have a great day.
00:43:44 <ramineni_> ekcs: have a great week, bye
00:44:35 <ekcs> #endmeeting