14:00:06 #startmeeting oslo 14:00:07 Meeting started Mon Aug 14 14:00:06 2017 UTC and is due to finish in 60 minutes. The chair is gcb. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:08 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:10 The meeting name has been set to 'oslo' 14:00:18 courtesy ping for amotoki, amrith, bknudson, bnemec, crushil, dansmith, dhellmann 14:00:20 courtesy ping for dims, dougwig, e0ne, electrocucaracha, flaper87, garyk, gcb 14:00:20 courtesy ping for GheRivero, haypo, jd__, jecarey, johnsom, jungleboyj, kgiusti 14:00:20 courtesy ping for kragniz, lhx_, lifeless, lxsli, Nakato, ozamiatin, rbradfor 14:00:20 courtesy ping for redrobot, rpodolyaka, sergmelikyan, sileht, spamaps, sreshetnyak, sreshetnyak 14:00:23 courtesy ping for stevemar, therve, thinrichs, toabctl, viktors, zhiyan, zzzeek,zxy 14:00:47 o/ 14:00:59 @! 14:01:00 <_pewp_> jungleboyj |。･ω･|ﾉ 14:01:10 o/ 14:01:37 o/ 14:01:46 hello everyone \o/ 14:01:47 o/ 14:02:11 #topic Red flags for/from liaisons 14:02:36 Nothing from Cinder. We are just trying to get everything stable for release. :-) 14:02:45 jungleboyj, thanks 14:03:09 I didn't find failures in http://status.openstack.org/openstack-health/#/?groupKey=build_name&resolutionKey=hour&searchProject=-with-oslo 14:03:33 #topic Releases 14:03:37 ./ 14:03:53 nothing from trove, trying to stabilize our gate 14:03:54 hi amrith 14:04:06 amrith: ack 14:04:57 there is no release patch this week, will hold master branch releases until cycle Queues open 14:05:01 hi gcb, at some point I'd like to know what the oslo plans are for the queens release so we can plan on those integrations/changes early. We're strapped for people and I don't want to find ourselves in a crunch late in the release cycle with a broken release. 14:05:22 this includes obsoleting/deprecation, and required changes of any kind. 14:06:52 amrith: good point, I will summary the plans and potential changes for consuming projects at the beginning of Queues and then send out to dev ML 14:07:23 gcb, would be good to treat them similar to (not with the same community voting/participation thing) the cross project goals 14:07:33 not to derail your meeting 14:07:49 but the idea is that simple ML communication does not guarantee acknowledgement 14:07:56 really good point. oslo covers broad areas and it would be nice to share such plans 14:08:08 one of the things that came out of the software stewardship group was that positive acknowledgement was valuable 14:08:18 and as amotoki says, oslo covers a lot of land. 14:08:52 and therefore if we had this kind of changes with wide impact, having the same governance as the cross project goals, with a review tracking project compliance for example, we'd ensure no late surprises. 14:09:06 I would also like to fix trove so we work regularly with the tip of oslo so we catch these things early. 14:09:16 but given that most of troves gate is red these days, it may not be a big win. 14:09:20 * amrith shuts up 14:10:20 amrith: thanks for the suggestions, sorry for the gate failure due to oslo stuff, agree we will find a way to communicate clearly :-) 14:10:33 amrith: if you have some worth shared and gathering interests from specific group(s), it might be a good idea to have some meeting topic to share updates 14:10:38 maybe we can add this as one topic for PTG 14:10:38 it might help communications 14:10:53 gcb, sure thing. I plan to be at PTG 14:10:57 can chat more there 14:11:23 amrith: cool , thanks amotoki 14:11:37 okay let's move on 14:12:03 we must revert https://review.openstack.org/#/c/493514/ due to it seems like a feature backport 14:12:42 otherwise we can't issue new releases for stable/ocata, oslo core reviewers please look at this when you're free 14:13:02 #topic A new Keystone-Oslo hook for external PDP 14:13:42 ruan__he: it's your turn 14:13:48 this is a topic discussed in the last keystone-policy meeting 14:14:02 background http://lists.openstack.org/pipermail/openstack-dev/2017-August/120955.html 14:14:31 the main idea is to use an external policy engine instead the native oslo.policy based on policy.json 14:15:38 ruan_he: so it doesn't need restart service if we change the police rules in external policy engine, right ? 14:15:47 yes 14:16:28 and the policy engine will work for all the services instead of one policy.json per service 14:16:52 and administrator can edit the policy rule online, that sounds a great feature 14:17:08 dims: around ? 14:17:15 exactly what we plan to do 14:18:26 from neutron perspective, it has several neutron-specific policy definitions, so it would be nice if we can provide compatibility. 14:18:34 anther important feature is that it will work at the same time for openstack and other sdn controllers like opendaylight: https://git.opendaylight.org/gerrit/#/c/46146/ 14:18:47 (we would like to clean them up, but it will take time) 14:20:10 this is only a supplementary option, you can continue use your policy if you like. for those who don't want, they can activate this option with an external engine like Apache Fortress 14:21:07 if you look at the odl commit, it has been already integrated in Carbon 14:21:13 ruan__he, amotoki: compatible policy definitions is import 14:21:48 generally I am fan of this kind of work which leverage and share useful features with open source communities anyway 14:22:22 gcb, I totally agree with you. That's why we propose a hook at the first time, and then we can test the policy compatibility 14:22:58 only discussion without code cannot move on the policy topic 14:23:15 ruan__he: we need figure out more details and collect inputs from others before implement it 14:24:17 there is a prototype proposed by Mirantis: https://review.openstack.org/#/c/237521/ 14:24:24 ruan__he: I would encourage oslo team review your spec review https://review.openstack.org/#/c/492543/ 14:24:57 we need to re 14:25:18 we need to re-discuss this topic in the next week's meeting? 14:26:18 ruan__he: we aslo consider how to migrate policy.json based implements to external PDP, anyway I will add comments in your oslo-specs review 14:27:01 for me, these 2 are in parallel 14:27:47 ruan__he: do you mean they work at the same time ? 14:27:51 ruan__he: (just for confirmation) what are 'these 2'? 14:28:16 reviews 237521 and 492543? 14:28:33 no, not at the same time, either policy.json or external engine 14:29:17 237521 is only for your information as a prototype, in 492543 we would like to provide a generic hook 14:30:13 ruan__he, Is it possible that neutron uses policy.json way but nova use external PDP way 14:31:26 gcb, I'll try to think about it. cannot answer you now 14:32:03 Are external engines global for other services? 14:32:29 zxy, what does global mean? 14:34:03 For example, Nova and neutron get the same policy? 14:35:31 from the external policy engine side, admin can firstly setup a global policy, and then the policy engine will translate it into the policy for each service 14:36:31 ruan__he, what I expect is that new way to access policy engine is optional without changing default behavior and provide good document to describe the new way and consider the deployment change 14:37:27 we share the same idea 14:37:39 I think it is a kind of translation or conversion. what we need is some compat way to provide policies to individual services 14:38:31 it does not matter a lot how "global" policies are defined (as policy consumers) 14:38:45 ruan__he, 14:38:45 That's a good idea, but you need to consider the mapping with other service action 14:38:47 amotoki: ++ 14:39:24 we have testes with Nova and Swift, it works well 14:39:56 ruan__he: it sounds a good startline 14:40:53 if you agree, we can do in 2 steps: first integrate the hook, second test different policy mechanism (translation, one policy per service) 14:42:11 ruan__he: you also need consider how to generate all policies automatically. like ok, second test different policy mechanism (translation, one policy per service) 14:42:58 sorry I mean https://github.com/openstack/nova/commit/5e38fa3cb5ae850dcf2bb251b4098220424a6ed6 14:44:10 this depends more on different external policy engine 14:44:14 we set "in-code policy definition" as our community goal for Pike, so I think we can generalize our current policies and it will help your thought, ruan__he 14:44:29 s/Pike/Queens/ 14:45:31 as your opinion, it is possible to add the hood for Queen? 14:45:53 ruan__he: generally I like the idea we need approve your oslo-specs review then we can review your implement code 14:46:28 ruan__he: I'm not sure 14:48:11 i'm not sure either, but i think you have a chance to have a hook? which provides policies compatibile with the current one 14:48:25 the time is tight, we can discuss more on next weekly meeting if we need 14:48:31 it would be great if we can have it in Queen, then we can start working on the policy engine as we discuss 14:49:36 ruan__he: is that okay ? 14:49:49 yes, ok for me 14:50:26 #topic Open discussion 14:51:14 I just nominate Andy Smith as oslo.messaging core reviewer, please vote for +1/-1 14:51:29 that's the only thing I want to raise 14:52:35 ruan__he, amotoki : continue your discussion in openstack-oslo if we need :-) 14:52:46 hey guys, since we're now at the open discussion topic, any chance someone could look over this change? https://review.openstack.org/#/c/492081/ we're having issues with exec calls on Windows. 14:53:36 gcb: ruan__he: thanks. i have no topic around policies at now. 14:53:53 lpetrut: thanks for addressing my comment, will look at it tomorrow 14:54:15 amotoki: thanks for your input 14:54:29 gcb: sure, thanks 14:55:57 any topics ? 14:56:09 we have last 5 minute :-) 14:59:12 thanks everyone 14:59:22 #endmeeting