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