14:00:39 #startmeeting neutron_drivers 14:00:40 Meeting started Fri Apr 12 14:00:39 2019 UTC and is due to finish in 60 minutes. The chair is mlavalle. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:42 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:44 The meeting name has been set to 'neutron_drivers' 14:00:51 hi 14:00:52 hi 14:01:09 o/ 14:02:44 Hi there 14:02:56 amotoki indocated he won't be able to join us 14:03:15 hi 14:03:21 his flight is delayed. I find it hard to beleieve that flights also get delayed in Japan ;-) 14:03:31 :D 14:05:15 so let's get going 14:05:22 #topic RFEs 14:05:31 The first one for today is https://bugs.launchpad.net/neutron/+bug/1821208 14:05:34 Launchpad bug 1821208 in neutron "[RFE] Only enforce policy when selected option does not match default" [Wishlist,Confirmed] 14:06:55 Yes, this one comes from me 14:07:57 The basic idea is that it is confusing for users if the supply some configuration in an api call that by policy they would not be allowed to supply - except the value they supplied was the default anyway. 14:09:17 in what situations / use cases would that happen? 14:09:56 mlavalle: e.g. in horizon 14:10:39 I've heard this a few times over the years. The horizon case is just the most recent one. 14:10:57 if there is "port_security" checkbox regular user can't create port even if this option was checked same as default value is 14:11:18 ^ yes that is the horizon issue I was just about to explain 14:12:05 another possible option for such issues would be maybe to provide some mechanism to discovery attributes which user can set and use that in horizon for example 14:12:17 but I have no idea how hard it would be to implement 14:12:44 njohnston's proposal seems simpler and to the point 14:13:09 mlavalle: yes 14:13:22 and I think that njohnston's proposal is basically good 14:13:32 but I also know that amotoki had some concerns about it :) 14:13:35 A few years ago I was mentoring someone in openstack, and it was a frustration she had too; she wanted to create a network and she could but if she created a network where shared=false she couldn't; she didn't undestand why we weren't focused on the outcome of the call, since she didn't yet understand how to discover what things she was and wasn't able to do by policy 14:13:45 is amotoki saying horizon should not display the check box in that case? 14:14:29 yamamoto: yes, but how horizon should know now when to display this box and when not? 14:14:51 by looking policy.json? 14:15:27 I think amotoki expressed that this is a change that could have security impacts, which I recognize, especially if it is not implemented very rigorously. 14:15:27 yamamoto: how horizon knows neutron's policy.json? 14:15:56 I did ask for any specific concerns; I wonder if we should table discussion intil he can be here and he has a chance to bring up any he has discerned 14:16:06 slaweq: i don't know. i just read amotoki's comment. :-) 14:16:23 yamamoto: ok :) I though that maybe You know something which I missed :) 14:17:05 yamamoto: so based on amotoki's comments I said at the beginning that as an alternative solution we can try to create some discovery mechanism 14:17:32 so horizon does embed policy.json files for neutron, nova, and possibly others 14:18:04 https://docs.openstack.org/horizon/latest/configuration/settings.html#policy-files 14:19:56 what I have noticed is that there seems to be a specific flavor of programmer out there that wants to supply all possible options to a given operation to remove the ambiguity of what code might default to 14:20:02 so it knows our policy 14:20:15 I've seen this especially when dealing with people coming from a military or government coding paradigm 14:21:38 I tend to be like that 14:22:21 for example, in my devstack settings, I try to set neutron params explicitely 14:23:20 it sounds a bit strange to me to include options rejected by policy in "all possible options" 14:23:35 * mlavalle is not military by any stretch of the imagination.... just a little ocd 14:24:29 and when I have had to explain why neutron forbids them specifying an option because of a policy concern even though the resultant VM would be the same - because what they are specifying was the default - each time I have had to answer the question "why should neutron care if there's no change to the end product? 14:24:35 And I respond by saying "well neutron checks whether you're allowed to specify a thing before it even looks at what the thing is you're specifying", which whiole true is a sort of neutron-programmer-centric view of things that I think isn't a great user experience 14:25:22 \what happens with other projects? 14:25:28 say Nova 14:25:46 maybe we are the odd ones 14:26:08 mlavalle: I don't know about nova. But when I started looking in to this I asked the in #openstack-oslo, and those people pointed me to the keystone folks 14:26:13 maybe we should send an email and ask community and e.g. API SIG about how it should be done? 14:26:36 yeah, I was thinking of the API SIG guys 14:26:49 Keystone actually has their policy.enforce call in a decorator and so asserts it in a per-method form, so some api calls are governed by policy but maybe others are done differently 14:27:31 well maybe this would trigger a conversation with API SIG that will unify the approache 14:27:39 approaches^^^^ 14:27:44 They commended the way Neutron does it, right at the start of api request processing, as being more paintainable 14:27:48 https://opendev.org/openstack/neutron/src/branch/master/neutron/api/v2/base.py#L469 14:28:07 but they said that it is done that way partially so that a project could do prevalidation of this sort if it wanted to 14:30:24 overall, I lean towards approving this RFE 14:30:29 would you like me to write to openstack-discuss and solicit opinions from the API SIG? 14:30:49 I see njohnston_ usability / consistency point 14:31:15 I would like to hear, though, amotoki's potential security concerns 14:31:52 mlavalle: I absolutely agree; amotoki is wise, and I want to make sure that if there is any possibility of opening a vulnerability with this that it is avoided 14:32:35 and since we are going to wait for a week to hear from him, we might as well ask the API SIG opinion 14:32:54 mlavalle: Very good, I will send an email. 14:33:05 does that work for everybody? 14:33:36 +! 14:33:37 +1 14:33:38 is it always trivial to check if the given value is same as the default? 14:33:58 With policy.code it's not hard I don't think 14:34:39 * haleyb spaced on meeting 14:35:00 for defaults specified in RESOURCE_ATTRIBUTE_MAP maybe it's easy 14:35:24 I'm not sure how it will work for api extensions, but that is an implementation issue 14:35:44 but i wouldn't be surprised if there are some plugins which computes the default more dynamically 14:36:46 there might be some cases where we can't compute the default and so we can't offer this kind of helpful behavior. I think we still achieve some benefit by doing what we can with checking static defaults. 14:36:47 in that case, let's confine this RFE to deafults in RESOURCE_ATTRIBUTE_MAP 14:37:08 and we can even document that behavior 14:37:17 I agree with mlavalle 14:38:25 yamamoto's point is good, though 14:38:32 subtle as usual 14:38:59 makes sense 14:39:39 so to summarize: 14:39:40 i suspect it isn't always obvious to api users if an attribute falls in the category or not 14:41:46 agree, but we can strive to document that if there are exceptions to the behaviour it is due to the fact that the plugin in question computes the default dynamically, / non - standadr way 14:42:20 so here's what I propose as inerim decisions on this RFE: 14:43:25 1) delimit this change to defaults in RESOURCE_ATTRIBUTE_MAP and document that if the default is not in the map the bahvior might not be the same 14:43:40 2) Solicit input from the API SIG 14:43:49 3) Discuss with amotoki next week 14:43:56 does this work? 14:44:14 yes definitely 14:44:30 good for me 14:44:59 sounds good 14:46:06 cool 14:46:27 let's try to get to the next one: 14:46:36 https://bugs.launchpad.net/neutron/+bug/1823633 14:46:37 Launchpad bug 1823633 in neutron "[RFE] L3 - netfilter Contrack Helper Support" [Wishlist,New] 14:47:16 while the other read through it, haleyb did you get the feedback you were going to ask on this one from someone in Red Hat? 14:47:38 mlavalle: no, not yet, i will ping him again today 14:47:51 haleyb: ok 14:48:19 haleyb: how would his feedback change this? 14:49:09 just if he said, "your in a namespace, just enable it", instead of loading just what we need 14:50:14 in that case, no change would be needed 14:50:50 right, but i don't think he'll say that after reading through the blogs, etc, it's a remote chance 14:52:05 yes, I think so. and it seems to me that more than a RFE, this is potentially on the brink of becoming a bug if we don't get ahead of the curve 14:54:34 +1 14:54:42 +1 14:55:32 +1 14:57:43 should we approve it? 14:57:49 I say yes 14:57:50 so, right now it behaves differently among distros, and this rfe doesn't make them consistent? 14:58:29 my understanding is that with this change, the behavior will be consistent accross distros 14:58:30 or are we going to disable the helper regardless of distros' default? 14:59:00 That is my understanding, since it is anyway the best practice 14:59:15 ok, then it makes sense 14:59:20 yes, it could be different, but i think every new distro release could disable it by default 14:59:20 +1 for approve 14:59:43 at least we recommend to disable it, right? 14:59:51 yes 14:59:57 +1 15:00:04 are all the others ok with approving? 15:00:07 +1 15:00:22 I'll make a note that this should be consistent accross all distros 15:00:37 ok, thanks for attendingQ! 15:00:43 have a nice weekend! 15:00:47 #endmeeting