00:00:51 #startmeeting congressteammeeting 00:00:52 Meeting started Thu May 11 00:00:51 2017 UTC and is due to finish in 60 minutes. The chair is ekcs. Information about MeetBot at http://wiki.debian.org/MeetBot. 00:00:53 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 00:00:56 The meeting name has been set to 'congressteammeeting' 00:01:03 ekcs: hi 00:01:27 hi all! welcome back to another meeting. collaborative list of topics are kept here as usual: https://etherpad.openstack.org/p/congress-meeting-topics 00:01:30 hi ramineni_ 00:02:50 ekcs: howz the summit going on? 00:04:40 it’s going well. got to participate in some interesting discussions around rbac, hierarchical quotas, api microversioning, deprecating postgres, etc. 00:06:18 ekcs: ohk, great 00:06:41 ok let’s move along then =) 00:06:51 #topic gate failure 00:07:21 looks like you’ve resolved/worked around the two main issues, devstack and keystone v2? 00:07:46 ekcs: yes, but still one issue is pending 00:07:55 thanks a ton! 00:08:00 what’s the pending issues ramineni_ ? 00:08:17 dealing with the remaining keystone v2 stuff? 00:08:23 ekcs: HA tests and keystone v2 tests are disabled as of now 00:09:20 ekcs: yes , with the removal of v2 v3 in the auth_url, v3 is working staright forward , but still need to figure out identifying v2 00:09:46 HA test problem is also we are using idnetity v2 clients for creation of replica 00:10:26 ah I didn’t notice the HA stuff. so is that just a matter of changing to v3 in the way replicas are created? 00:10:37 ekcs: and also, you remember making the local copy of manager file which used to be in tempest? 00:10:48 yes 00:11:27 ekcs: any idea, if can remove this and use directly 00:11:29 https://github.com/openstack/congress/blob/master/congress_tempest_tests/tests/scenario/manager.py 00:13:17 ekcs: this part is failing in HA , https://github.com/openstack/congress/blob/master/congress_tempest_tests/tests/scenario/congress_ha/test_ha.py#L45 00:13:53 ekcs: taking v2 here , have to use right client here and test it ..ill get to that this week 00:14:28 thanks so much for figuring stuff out! 00:14:58 ok ramineni_ said: “any idea, if can remove this and use directly https://github.com/openstack/congress/blob/master/congress_tempest_tests/tests/scenario/manager.py” 00:15:18 I’m confused what “this” refers to. what are you proposing to remove? 00:15:48 ekcs: local copy, the link i mentioned 00:17:19 can we remove this https://github.com/openstack/congress/blob/master/congress_tempest_tests/tests/scenario/manager.py” 00:17:21 ? 00:17:25 ok yea mean remove the local copy you linked and use tempest library directly. 00:17:31 ekcs: yes 00:18:15 I would think no because the idea is tempest team is going to take some time to refactor things and create stable interfaces. 00:18:32 when they’re done we’ll rework things to use their new interfaces. 00:18:42 ekcs: ok 00:18:50 in the mean time, if we use their library directly, things will break as they make changes. 00:19:05 unless they’re already done, but i haven’t seen any notice on ML. 00:19:24 just did a search again to be sure. nothing on ML. 00:19:38 ekcs: ok, got it. 00:19:41 does it help us/you to remove? 00:20:24 ekcs: no 00:20:51 oh ok. well i’ll monitor the ML and when i hear update from tempest team I’ll let people know. 00:20:54 ekcs: I better not create new failures by touching that file :) 00:21:00 hehe. 00:21:12 ekcs: great, thanks 00:21:31 ekcs: In the meanwhile , can we merge to resolve the gate failure as of now.. ? 00:21:56 ok one last thing. in what you’ve looked at so far, do you know if keystone v2 is supposed to work (we just use it wrong) or not supposed to work at all? 00:22:03 ekcs: local devstack failing because of the issues, so we need that patch to be merged asap 00:22:21 yup I think we should merge it. I already +1ed. 00:22:38 you can go ahead and +2/+1 00:22:58 ekcs: i couldnt get anything, i have checked the keystone latest commits, nothing of deprecation related 00:23:23 ekcs: change in auth_url , may be we have to change the way we are detetcting its v2 00:23:47 ok hmm. maybe i’ll ask one of the keystone folks at the summit hehe. ok thanks! 00:24:04 do you have the keystone patch handy that changed the auth_url expected? 00:25:51 ekcs: you meant this one https://review.openstack.org/#/c/458449/ 00:25:52 patch 458449 - openstack-dev/devstack - try to use unversioned keystone endpoints everywhere (MERGED) 00:27:22 hmm ok. yea I see that devstack patch, was wondering if we know the keystone patch that made this necessary. 00:27:52 from there we may be able to figure things out. 00:28:13 there must have been a change on keystone that made the versioned auth_url not work. 00:28:35 ekcs: yes, ok, couldnt find it as of now 00:28:37 not necessarily easy to track down tho. 00:28:41 yea. ok. great 00:28:54 if i get hold of a keystone guy i’ll ask =) 00:29:14 ekcs: great :) 00:29:59 ok well lets move on then? 00:30:45 yes 00:32:03 #topic policy library 00:32:28 ok too bad no thinrichs and masahito, but let’s see what we can do. 00:32:33 thanks for the comments. 00:32:43 on #link https://review.openstack.org/#/c/457880/6/specs/pike/policy-library.rst@96 00:32:44 patch 457880 - congress-specs - policy library spec 00:33:15 ekcs: yep, i was just wondering if we have explored that option ? 00:34:28 ekcs: and still couldnt get why we need to store template policies in DB ? and if we want to store, can u update inthe spec, what all details we are storing? 00:34:44 ekcs: is it just the id, or all details? 00:35:11 ok so there are two things. 00:36:17 for whether to go actual templates instead of plain policy that can be editted: thinrichs came up with that design. I think the idea is we may not have time this cycle to figure out all the details needed to deal with templates (what syntax, would it interfere with existing rule syntax? do we need new parser grammer?, what gui, etc) 00:36:32 so we can get almost all the benefit without explicitly doing placeholders. 00:36:49 just use normal variables/constants, and choose names that make it clear users can edit them. 00:37:47 do you see a major benefit of using templates instead of actual policies users can edit? 00:38:26 Hi all. Sorry I'm late—got caught up (again) 00:38:41 thinrichs: hi 00:38:57 ah you’re here just in time for the pol lib discussion. 00:39:28 we’re talking about ramineni_ ’s comment here: https://review.openstack.org/#/c/457880/6/specs/pike/policy-library.rst@96 00:39:28 patch 457880 - congress-specs - policy library spec 00:40:02 ekcs: hmm , i saw using jinja2 is easier , so proposed that option , but may be for next cycle as you mentioned 00:40:18 ekcs: for whether to go actual templates instead of plain policy that can be editted: thinrichs came up with that design. I think the idea is we may not have time this cycle to figure out all the details needed to deal with templates (what syntax, would it interfere with existing rule syntax? do we need new parser grammer?, what gui, etc) 00:40:18 [5:36pm] ekcs: so we can get almost all the benefit without explicitly doing placeholders. 00:40:35 that’s what I said. anything correction/addition thinrichs ? 00:42:06 ekcs: nope—that was the thought. That a template is a lot of work, and people will want to modify things more than a template provides (eventually) anyway. 00:42:40 There's nothing stopping us from adding the functionality of templates later 00:42:47 thinrichs: ya, ok 00:43:45 ok the other issue is why do we persist the policy library in DB. 00:44:56 what model do you have in mind ramineni_ ? 00:45:01 My thought there was if we store them in the DB then it's easy to make them accessible via the API 00:45:21 which we'd need to do, esp for Horizon 00:45:50 thinrichs: after modifying or before modfying? 00:46:27 Both. The policy "library" has its own API and policies contained within it are not active. (Eventually these could be raw policies or templates.) 00:47:08 thinrichs: if user wants to use only 2/3 policies of it? still we load all the policies into DB 00:47:17 Then the user wants to apply/instantiate a policy from the library and make it active. 00:47:48 The library DB tables would be completely separate from the current Policy/Rule tables. 00:48:17 The library DB tables have their own CRUD operations to add new policies, look at the ones that exist, update, and delete. 00:48:33 All those operations would be completely independent of our current CRUD operations on Policies/Rules. 00:48:59 thinrichs: what details are we storing in DB for policy libraries? same as policy table? 00:49:29 I believe so. Not sure if there are any extra fields we'd want. The spec might cover that. 00:49:54 ramineni_: https://review.openstack.org/#/c/457880/6/specs/pike/policy-library.rst@96 00:49:55 patch 457880 - congress-specs - policy library spec 00:50:13 here is the table I propose in the spec 00:50:23 ugh nvm 00:50:24 wrong link 00:50:27 The difference is most obvious with execute[] rules. The execute[] rules in the Library tables would never fire; but the execute[] rules in the Policy/Rules tables would fire. 00:50:58 Said another way, the Policy Engine would never see any of the Library policies (until they were inserted into the Policy/Rules tables). 00:51:04 https://review.openstack.org/#/c/457880/6/specs/pike/policy-library.rst@209 00:51:05 patch 457880 - congress-specs - policy library spec 00:51:27 thinrichs: hmm, so user would edit the polciies in files or using API? 00:52:18 thinrichs: sample policies** 00:52:38 the API is how congress server sees it. 00:52:50 but CLI would support referencing a file. 00:53:07 and passing it along to server using API. 00:53:19 horizon would have edit box. but again pass it along to server using API. 00:53:55 in the current spec proposal anyway. 00:54:16 Looking at the sample policies, I'd think most of the time people will want to edit them before instantiating them (templating might make that easier). 00:54:29 In Horizon, that editing could be done in an edit box, as ekcs suggests. 00:54:54 From the CLI it's unclear to me, but I'd imagine pulling the policy into a file, having the user edit it, and uploading the file. 00:55:14 The CLI could also stitch together the download + upload APIs into a single command 00:55:30 for those cases when the user doesn't want to edit 00:56:41 When we support templates, I'd imagine the user would want to instantiate the template with given parameters. 00:56:49 in either `policy create` or `library policy create` the CLI can accept either the policy with all rules in json/yaml as well as path to file. 00:57:27 in `policy create`, an additional option is to create directly from a policy stored in the library, by referencing it’s name. 00:57:50 a deployer may have already edited that policy in the library to be suitable for the particular setup. then an admin can simply activate it this way. 00:58:25 So the CLI would be something like "openstack congress library install ", which would under the hood (a) pull down the template, (b) run the template, (c) upload the instantiated policy. (We could move some/all of that to the server too) 00:58:46 (The above was for the templated case.) 00:58:53 down the road 00:59:00 thinrichs: yes, thats what i had in mind 00:59:00 Here’s the proposed API for activating directly from library without editing. https://review.openstack.org/#/c/457880/6/specs/pike/policy-library.rst@609 00:59:01 patch 457880 - congress-specs - policy library spec 00:59:37 well we’re out of time. let’s continue on gerrit =) 01:00:08 ekcs: ok 01:00:15 Ok 01:00:25 or we could contine on #congress if interested. 01:00:34 anyway i’ll be on congress. 01:00:38 see you next time! 01:00:41 #endmeeting