22:03:54 <kevinbenton> #startmeeting neutron_drivers 22:03:55 <openstack> Meeting started Thu Apr 27 22:03:54 2017 UTC and is due to finish in 60 minutes. The chair is kevinbenton. Information about MeetBot at http://wiki.debian.org/MeetBot. 22:03:56 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 22:03:58 <openstack> The meeting name has been set to 'neutron_drivers' 22:05:22 <kevinbenton> let's go over some stuff that has been approved but is sitting in spec phase 22:05:25 <kevinbenton> #link https://review.openstack.org/#/q/project:openstack/neutron-specs+is:open 22:06:20 <kevinbenton> #link https://review.openstack.org/#/c/396297/ 22:06:33 <kevinbenton> rfe-approved for this one 22:06:56 <kevinbenton> but ajo has changed focus IIRC 22:07:10 <mlavalle> I have been following that one 22:07:12 <ihrachys> yes 22:07:44 <kevinbenton> i think we need a blueprint for this one to track priority 22:07:44 <mlavalle> In fact, I am listed in that spec to implement part of it 22:07:54 <slaweq> I think that ralonsoh is now on it (but You should ask him) 22:08:18 <kevinbenton> mlavalle: can you file a quick blueprint for it that links to the RFE and the spec? 22:08:28 <mlavalle> kevinbenton: yes I will 22:08:44 <mlavalle> Just to let you know, I am attending the QoS meeting regularly 22:09:01 <kevinbenton> ok and i see you're reviewing the spec so it's getting attention 22:09:06 <kevinbenton> let's move onto the next one 22:09:08 <mlavalle> trying to fill the void left by ajo and give the a core that follows the regularly 22:09:24 <mlavalle> them and them ^^^^ 22:09:33 <kevinbenton> mlavalle: i can help with reviews for the code as well when it comes time for the implementation 22:09:41 <mlavalle> cool! 22:09:55 <kevinbenton> #link https://review.openstack.org/#/c/333993/ 22:10:03 <ihrachys> I am reviewing that one 22:10:19 <ihrachys> I think there are several outstanding issues around API uris 22:10:30 <ihrachys> it made a long way 22:10:37 <ihrachys> and I think we are close to getting it in 22:10:51 <kevinbenton> ok, there is one other issue that Igor had reached out to me about 22:10:51 <ihrachys> at which point kevinbenton will probably work with folks to get them +2s in the repo 22:11:05 <kevinbenton> the repo 22:11:18 <kevinbenton> did they get it figured out if the old code was just going to be deleted? 22:11:25 <ihrachys> deleted 22:11:31 <ihrachys> minus maybe some scaffolding 22:11:35 <kevinbenton> ok 22:11:59 <kevinbenton> ihrachys: can you file a shim blueprint for that one as well? 22:12:06 <ihrachys> will do 22:12:45 <kevinbenton> I'll defer https://review.openstack.org/#/c/456394/ until we are discussing rfes 22:13:17 <kevinbenton> #link https://review.openstack.org/#/c/452677/ 22:13:58 <kevinbenton> i need to review that one 22:14:14 <kevinbenton> nothing the team needs to discuss there 22:14:35 <kevinbenton> #link https://review.openstack.org/#/c/203509/ 22:15:01 <kevinbenton> i think we're short an approver on this one 22:15:23 <kevinbenton> it's currently assigned to Rossella 22:15:30 <yushiro> kevinbenton, yes. 22:15:54 <yushiro> kevinbenton, she just asked me 1 question about a result of PTG discussion. 22:16:15 <yushiro> I just replied to her earlier this week. 22:16:27 <kevinbenton> yushiro: ok, have we finally reached a point where we have general agreement on the API? 22:17:06 <yushiro> kevinbenton, sure. Regarding an API design, rossella agreed with our one. 22:17:18 <ihrachys> I think a more serious issue was re validation in multi driver env, and we stated before that the framework should be laid for that in ml2 (which I don't know whether there were any moves) 22:17:56 <yushiro> ihrachys, sure. In my understanding, QoS has implemented a validation logic. 22:18:03 <ihrachys> I see yushiro refers to qos patch, but that's not directly applicable to the proposed feature 22:18:39 <ihrachys> that would require quite some generalization to make it applicable 22:19:02 <yushiro> ihrachys, aha. OK. I understand that is not generic approach now. https://github.com/openstack/neutron/blob/master/neutron/services/qos/qos_plugin.py#L48-L55 22:19:18 <ihrachys> so the question here is probably: 1. do we still think that blocking the logging feature for lack of validation is the right thing to do; 2. if so, who works on the validation framework? 22:19:35 <kevinbenton> ihrachys: i have a qos question 22:19:46 <ihrachys> I think armax had strong feelings about it in the past. 22:19:56 <kevinbenton> ihrachys: how do you know which driver will be required to support a policy applied to a network? 22:20:38 <slaweq> kevinbenton: in qos validation it checks if each port in network can support rules from such policy 22:20:39 <ihrachys> I don't remember details. maybe slaweq has an answer? 22:21:08 <yushiro> ihrachys, hmm, I'd like to avoid blocking more.. For ex, firstly Logging refers QoS mechanism and fixes logic after same as QoS.. 22:21:17 <ihrachys> slaweq, ...unless ports have overridden policies I believe 22:21:25 <slaweq> ihrachys: yes 22:22:03 <kevinbenton> but what happens if a port is added later? 22:22:09 <ihrachys> yushiro, if you have a solution for validation for the feature, I don't think we should block on generic mechanism. 22:22:35 <kevinbenton> do you cause a binding failure? 22:22:43 <slaweq> kevinbenton: it also validate on port create event 22:22:53 <kevinbenton> slaweq: ok 22:23:01 <slaweq> so it will fail if driver can't support QoS rules 22:23:10 <kevinbenton> makes sense 22:23:15 <ihrachys> and when you bind. the idea is not getting into that db state in the first place. 22:23:24 <kevinbenton> so we will need to do the same here 22:23:36 <kevinbenton> since port can be associated with sg group before it is associated with a driver 22:24:07 <ihrachys> right. and I guess there could be some space for code reuse, just not as-is, would need some refactoring. 22:24:23 <yushiro> ihrachys, currently, I don't have generic solution. Is it necessary during Pike cycle? 22:24:44 <ihrachys> I think as long as we state that we desire validation as part of the feature, it can proceed, even if it doesn't settle common framework in advance. 22:24:56 <kevinbenton> i'm okay if we don't have a generic solution and just validate similar to qos 22:25:01 <ihrachys> + 22:25:12 <kevinbenton> having two different use cases can make it easier to visualize a generic framework later 22:25:29 <mlavalle> yep 22:25:41 <yushiro> kevinbenton, aha, Sure. So, in this cycle, Logging API will refer QoS solution. 22:25:49 <kevinbenton> right 22:25:52 <ihrachys> yushiro, yeah. reuse code where possible. 22:26:06 <kevinbenton> yushiro: can you update the spec summarizing our commentary here? 22:26:25 <yushiro> kevinbenton, Of course. After that, can we approve one? 22:26:31 <kevinbenton> yushiro: once rossella is happy with it, I can take over as approver for helping review code and getting other volunteers for components 22:26:57 <kevinbenton> reviews are much easier for me once we've all agreed on the API :) 22:27:05 <yushiro> kevinbenton, I understood. I'll tell her ultra super ASAP. 22:27:12 <yushiro> :) 22:27:15 <kevinbenton> yushiro: thanks :) 22:27:26 <kevinbenton> ok 22:27:28 <kevinbenton> #link https://review.openstack.org/#/c/374506/ 22:27:55 <kevinbenton> this looks like rfe isn't approved yet 22:28:00 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bug/1596611 22:28:01 <openstack> Launchpad bug 1596611 in neutron "[RFE] Create L3 IPs with qos (rate limit)" [Wishlist,In progress] - Assigned to LIU Yulong (dragon889) 22:28:38 <kevinbenton> ihrachys: are you familiar with where this one is at? 22:29:36 <ihrachys> I haven't reviewed the spec 22:29:41 <ihrachys> I know what's that about 22:29:45 <kevinbenton> ok 22:29:53 <ihrachys> the complexity of this thing would be enormous I suspect 22:29:58 <ihrachys> gotta look at proposal 22:30:01 <kevinbenton> i'll put back into triaged 22:30:08 <kevinbenton> so we can review with other RFE's 22:30:10 <ihrachys> I will have a look next week 22:30:27 <kevinbenton> #link https://review.openstack.org/#/c/452032/ 22:30:32 <kevinbenton> this is vpnaas assessment 22:30:41 <kevinbenton> I'll work with armax on reviewing this one 22:30:52 <kevinbenton> #link https://review.openstack.org/#/c/454788/ 22:30:55 <kevinbenton> this says don't review 22:30:58 <kevinbenton> so don't look at it 22:31:03 <mlavalle> LOL 22:31:21 <kevinbenton> #link https://review.openstack.org/#/c/445762/ 22:31:23 <ihrachys> oh now my eyes, they are burning, why have you sent it my way! 22:31:39 <kevinbenton> this still needs rfe review #link https://bugs.launchpad.net/neutron/+bug/1505627 22:31:41 <openstack> Launchpad bug 1505627 in neutron "[RFE] QoS Explicit Congestion Notification (ECN) Support" [Wishlist,Triaged] - Assigned to Reedip (reedip-banerjee) 22:31:57 <kevinbenton> ah 22:31:58 <kevinbenton> #link https://review.openstack.org/#/c/320439/ 22:32:09 <kevinbenton> I think this needed a new approver as well 22:32:28 <kevinbenton> #link https://blueprints.launchpad.net/neutron/+spec/l2-api-extensions 22:32:50 <kevinbenton> ihrachys: i had suggested the author reach out to Jakub, do you know if he is available? 22:33:12 <ihrachys> kevinbenton, for doing that work? I really doubt it. 22:33:23 <kevinbenton> ihrachys: being approver 22:33:25 <kevinbenton> not implementing 22:33:50 <ihrachys> yeah, but even then, I know that Kuba will take care about e.g. multiple port bindings, also some ovsfw bits... 22:33:56 <ihrachys> I don't think he is avail for that 22:33:58 <kevinbenton> ok 22:34:11 <ihrachys> you can try to reach out, but I would suggest we don't have resources to make it happen. 22:34:34 <kevinbenton> ack 22:34:54 <kevinbenton> i'll remove ajo from the approver field 22:34:57 <kevinbenton> so it's clear 22:35:27 <kevinbenton> #link https://review.openstack.org/#/c/445771/ 22:35:33 <kevinbenton> there was an RFE for this i recall 22:35:46 <kevinbenton> but it's not linked here 22:36:54 <kevinbenton> i will -1 and ask to link to rfe 22:37:17 <mlavalle> yeah, that's the easiest thing to do 22:37:38 <kevinbenton> #link https://review.openstack.org/#/c/236840/ 22:37:57 <ihrachys> that smells orchestration 22:38:17 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bug/1657084 22:38:18 <openstack> Launchpad bug 1657084 in neutron "[RFE]Add time period attribute to firewall_rule" [Wishlist,Incomplete] 22:38:23 <ihrachys> and it seems like the bug is Incomplete 22:38:26 <kevinbenton> rfe sounds like similar conclusion 22:38:27 <ihrachys> which makes sense 22:38:35 <ihrachys> so be it 22:38:38 <ihrachys> let's just -2 22:38:40 <kevinbenton> i'll -2 pending RFE 22:38:44 <ihrachys> + 22:39:19 <kevinbenton> #link https://review.openstack.org/#/c/446111/ 22:39:33 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bug/1673210 22:39:34 <openstack> Launchpad bug 1673210 in neutron "Enable MySQL Cluster Support" [Wishlist,Confirmed] - Assigned to Octave Orgeron (octave-orgeron) 22:40:08 <mlavalle> I think he even has a patch with the implementation 22:40:19 <kevinbenton> yes, i remember reviewing it 22:40:31 <kevinbenton> I don't think there is too much to discuss as a drivers team for this one 22:40:41 <mlavalle> https://review.openstack.org/#/c/446136/ 22:40:43 <kevinbenton> as RFE indicates it's a few minor fixes 22:40:43 <ihrachys> I read the spec real quick. does it suggest we reduce the size of .e.g names nad description for all resources?.. 22:40:50 <kevinbenton> oh 22:41:02 <ihrachys> line 82+ 22:42:08 <kevinbenton> yeah 22:42:12 <kevinbenton> that will need some explanation 22:42:13 <mlavalle> it seems like that to me 22:42:15 <kevinbenton> sounds like we can lose data 22:42:26 <ihrachys> and break api-ref conformity 22:42:46 <kevinbenton> the other problematic thing is in the patch here: https://review.openstack.org/#/c/446136/7/neutron/db/api.py@237 22:42:53 <kevinbenton> apparently no savepoint support 22:43:34 <mlavalle> it would be interesting to see how other projects are reacting to this 22:44:02 <mlavalle> he has similar patches with Nova, Cinder, etc 22:44:13 <ihrachys> +, sounds like a cross project thing to handle. there should be some common approach and source of knowledge. ideally, oslo.db folks would come to us and tell what to do. 22:44:55 <kevinbenton> ok, let's let it sit. i will also continue to ask questions on the patch 22:45:24 <kevinbenton> #link https://review.openstack.org/#/c/362008/ 22:45:48 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bug/1561824 22:45:49 <openstack> Launchpad bug 1561824 in neutron "[RFE] Enhance BGP Dynamic Routing driver with Quagga suppport" [Wishlist,Triaged] - Assigned to Steve Ruan (ruansx) 22:45:50 <kevinbenton> this is rfe-approved 22:46:33 <kevinbenton> but hasn't be reproposed to pike 22:46:37 <ihrachys> I see lately there is not much work happening on the repo so is it even realistic? 22:46:47 <kevinbenton> I think i will just abandon and ask to repropose it for pike 22:47:00 <kevinbenton> it's from IBM 22:47:04 <mlavalle> he used to attend the L3 meeting, with tidwellr was astill around 22:47:13 <kevinbenton> so they may have been moved off 22:47:19 <mlavalle> yeah 22:48:26 <kevinbenton> #link https://review.openstack.org/#/c/388398/ 22:48:31 <mlavalle> that sounded like being with IBM is a stigma LOL 22:48:53 <kevinbenton> mlavalle: nah 22:49:00 <mlavalle> kevinbenton: just teasing 22:49:05 <kevinbenton> mlavalle: :) 22:49:08 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bug/1633280 22:49:09 <openstack> Launchpad bug 1633280 in neutron "[RFE]need a way to disable anti-spoofing rules and yet keep security groups" [Wishlist,Incomplete] 22:49:24 <kevinbenton> this is pending feedback on rfe 22:49:36 <kevinbenton> i'll put -2 for now 22:49:56 <mlavalle> nothing has really happened since October 22:50:04 <mlavalle> thats more than 6 months ago 22:50:15 <kevinbenton> yeah 22:50:19 <kevinbenton> #link https://review.openstack.org/#/c/391654/ 22:50:38 <ihrachys> that one also didn't have much traction to say the least. 22:50:48 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bug/1592028 22:50:49 <openstack> Launchpad bug 1592028 in neutron "[RFE] Support security-group-rule creation with address-groups" [Wishlist,Triaged] - Assigned to Roey Chen (roeyc) 22:50:57 <kevinbenton> i'll -2 pending RFE approval 22:51:16 <mlavalle> pretty much the same story, well one month younger 22:51:24 <kevinbenton> #link https://review.openstack.org/#/c/392023/ 22:51:54 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bug/1505631 22:51:55 <openstack> Launchpad bug 1505631 in neutron "[RFE] QoS VLAN 802.1p Support" [Wishlist,Confirmed] - Assigned to Reedip (reedip-banerjee) 22:52:24 <kevinbenton> so this is rfe-postponed 22:52:59 <kevinbenton> mlavalle: do you know if anyone is trying to work on this for qos? 22:53:07 <ihrachys> do we have some seasoned qos contributors like slaweq interested in following it through? 22:53:23 <mlavalle> kevinbenton: I don't think it has been mentioned lately in the meetings 22:53:49 <slaweq> no, AFAIR it wasn't discussed on last few QoS meetings 22:54:11 <kevinbenton> ok, i'll put a -2 pending rfe revival 22:54:12 <slaweq> and if I'm right it was not clear what reedip excactly wants there 22:54:15 <mlavalle> ralonsoh is very thorough following up with the rfe's, bugs and patches 22:54:38 <ihrachys> there are already dscp marks for prioritization, it doesn't cover all infrastructures, but good enough for some. 22:54:50 <mlavalle> so if he hasn't mentioned it in the meetings, it's not in any radar screen 22:54:51 <kevinbenton> ok 22:54:52 <ihrachys> + for letting it die in LP 22:55:03 <kevinbenton> that was everything in the open state on neutron-specs 22:55:12 <kevinbenton> does anyone have anything to bring up in the last 5 mins 22:55:17 <kevinbenton> #topic open discussion 22:55:20 <ihrachys> I think slaweq had something to raise, and I feel like it's worth giving him the chance 22:55:28 <kevinbenton> slaweq: go ahead 22:55:32 <slaweq> thx 22:55:37 <slaweq> I wanted to talk about https://bugs.launchpad.net/neutron/+bug/1686035 22:55:38 <openstack> Launchpad bug 1686035 in neutron "[RFE] More detailed reporting of available QoS rules" [Medium,Triaged] - Assigned to Slawek Kaplonski (slaweq) 22:55:53 <slaweq> but I don't know if we will have time now 22:56:23 <ihrachys> on first sight, it looks like now we are in the business of API discovery 22:56:30 <slaweq> basically I think that we should change way how available rule types are "calculated" 22:56:38 <kevinbenton> slaweq: makes sense 22:56:43 <kevinbenton> slaweq: but is this operator only? 22:57:10 <ihrachys> slaweq, wouldn't making it just a concatenation of all supported rules be good enough? 22:57:18 <ihrachys> and then allowing users to hit validation? 22:57:25 <ihrachys> (more of a strawman) 22:57:33 <slaweq> ihrachys: exactly that's what I want to do 22:57:39 <kevinbenton> that sounds good 22:57:44 <kevinbenton> but if this is user facing 22:57:48 <kevinbenton> you can't show driver 22:57:48 <ihrachys> slaweq, but I see supported parameters mentioned in the desc? 22:57:51 <slaweq> now it get common subset of rules supported by all loaded drivers 22:58:14 <slaweq> but IMHO it should returns all rule types supported by at least one driver 22:58:35 <ihrachys> kevinbenton, existing api is definitely user available (assuming ops allowed that in policy, which is not an unreal situation) 22:58:36 <slaweq> later when rule/policy will be applied to port there will be validation done for this port 22:59:03 <ihrachys> slaweq, ok then if that's all you want, maybe remove driver notion from the description? also parameters? 22:59:07 <slaweq> so that's what I want to change in first point described there and IMO it's quite easy to do 22:59:10 <kevinbenton> ihrachys: existing api is leaking driver name to users? 22:59:16 <ihrachys> basically, same API, just different result? 22:59:21 <slaweq> but there is also second part 22:59:26 <ihrachys> kevinbenton, I don't think so. it's just a list of rule type names 22:59:50 <slaweq> and second part is to add new API call to display details of each rule type 22:59:50 <kevinbenton> slaweq: what is second part? 22:59:57 <ihrachys> slaweq, maybe split? I am ready to +2 a patch for the first part as a simple bug fix. 23:00:10 <kevinbenton> +1 23:00:15 <kevinbenton> first part is super easy 23:00:22 <slaweq> ihrachys: ok so I will propose patch for first part 23:00:33 <kevinbenton> we're out of time 23:00:36 <ihrachys> slaweq, so the 2nd part is tricky; it's api discovery, and you suggest to leak cloud infra details (drivers) 23:00:36 <slaweq> and what about second one? should I write some specs? 23:00:47 <kevinbenton> slaweq: another RFE 23:00:49 <kevinbenton> or update this one 23:00:59 <kevinbenton> for clear use case and who its visible to, etc 23:01:05 <kevinbenton> we can discuss next drivers meeting 23:01:09 <kevinbenton> thanks everyone! 23:01:10 <slaweq> kevinbenton: ok, I will update this rfe to only second part :) 23:01:11 <slaweq> thx 23:01:12 <mlavalle> o/ 23:01:13 <kevinbenton> #endmeeting