14:00:05 <mlavalle> #startmeeting neutron_drivers
14:00:06 <openstack> Meeting started Fri Feb  2 14:00:05 2018 UTC and is due to finish in 60 minutes.  The chair is mlavalle. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:09 <openstack> The meeting name has been set to 'neutron_drivers'
14:00:33 <yamamoto> hi
14:00:39 <slaweq> hi
14:00:52 <mlavalle> hey guys
14:01:15 <annp> hi
14:01:20 <SridarK> Hi
14:01:37 <mlavalle> hi annp, SridarK
14:01:48 <SridarK> mlavalle: hi
14:01:53 <mlavalle> waiting a to have quorum to get going
14:01:56 <ihrachys> o/
14:02:06 <mlavalle> welcome ihrachys
14:02:12 <mlavalle> now we have quorum
14:02:48 <mlavalle> amotoki will join the meeting 10 minutes late
14:03:24 <mlavalle> but we can get going looking at the RC1 dashboard: https://launchpad.net/neutron/+milestone/queens-rc1
14:03:38 <mlavalle> I spent some time last evening updating the status
14:04:06 <mlavalle> of the bugs. So I think the picture in the dashboard is pretty accurate
14:04:23 <mlavalle> as far as status
14:05:23 <yamamoto> can you update "Expected" date?
14:06:24 <yamamoto> it seems i'm not a member of drivers on LP
14:07:10 <mlavalle> I'll fix that after the meeting
14:07:51 <mlavalle> and I will monkey with the expected date also after that
14:08:05 * mlavalle wasn't paying attention to that
14:08:50 <mlavalle> SridarK and yushiro pinged me last evening because they want to add a couple of FWaaS bugs to RC1
14:09:15 <SridarK> mlavalle: yes thx
14:09:53 <SridarK> #link https://bugs.launchpad.net/neutron/+bug/1746404
14:09:54 <openstack> Launchpad bug 1746404 in neutron "'auto_associate_default_firewall_group' got an error when new port is created" [High,In progress] - Assigned to chandan dutta chowdhury (chandanc)
14:10:27 <SridarK> being addressed by #link https://review.openstack.org/#/c/539461/
14:10:28 <patchbot> patch 539461 - neutron-fwaas - Remove disable option for default FWG and allow on...
14:10:42 <SridarK> mlavalle: the first one
14:11:21 <mlavalle> actually jlibosva already marked them for the RC earlier this morning (my time)
14:11:33 <SridarK> mlavalle: ok perfect
14:12:09 <SridarK> I see #link https://bugs.launchpad.net/neutron/+bug/1746855
14:12:10 <openstack> Launchpad bug 1746855 in neutron "FWaaS V2 failures with Ml2 is Linuxbridge or security group driver is iptables_hybrid" [High,In progress] - Assigned to Nguyen Phuong An (annp)
14:12:11 <SridarK> added as well
14:12:22 <mlavalle> wanted to see if there are any concernes from the drivers team about adding these two bugs
14:12:54 <mlavalle> both bugs have already fixes up for review
14:13:14 <amotoki> hi, i have no concern on them as far as I discussed yesterday with fwaas team.
14:13:57 <ihrachys> also this would probably be material for rc1: https://bugs.launchpad.net/bgpvpn/+bug/1746996
14:13:58 <openstack> Launchpad bug 1746996 in neutron "bagpipe: IPAllocation DB query failing, engine facade mismatch" [Undecided,New]
14:14:07 <ihrachys> tmorin just asked about it in neutron channel
14:14:12 <SridarK> And both have been in review and almost ready to merge
14:14:12 <annp> amotoki, thanks
14:14:16 <SridarK> amotoki: thx
14:14:36 <ihrachys> I don't have concerns for fwaas
14:15:32 <chandanc> thanks amotoki ihrachys
14:15:40 <mlavalle> me neither
14:15:54 <yamamoto> why https://review.openstack.org/#/c/539461/ is removing a config option? (i just glanced patches)
14:15:55 <patchbot> patch 539461 - neutron-fwaas - Remove disable option for default FWG and allow on...
14:16:09 <yamamoto> otherwise no concerns
14:16:18 <annp> thanks mlavalle, ihrachys :)
14:16:22 <SridarK> ihrachys: thx
14:17:00 <mlavalle> ok, so we will add them to the RC and maybe we can address yamomoto's question in the review
14:17:04 <mlavalle> is that ok?
14:17:07 <annp> yamamoto: thanks. long time no see. how are you? :)
14:17:19 <ihrachys> mlavalle, +
14:17:33 <yamamoto> mlavalle: sure
14:17:39 <SridarK> yamamoto: earlier we thought we need an option to enable/disable applying default fwg - but this can pose issues due to conntrack
14:18:17 <yamamoto> annp: hi, i'm fine
14:18:19 <SridarK> yamamoto: we can discuss on gerrit as well so we dont take more time here
14:18:37 <yamamoto> SridarK: ok
14:19:04 <annp> yamamoto: :)
14:19:09 <mlavalle> SridarK, annp: thanks for showing up to the meeting :-). I know is really early for SridarK and maybe very late for annp
14:19:29 <SridarK> mlavalle: no worries at all thx
14:19:46 <annp> mlavalle: no worries, in vietnam just 9PM
14:20:05 <mlavalle> going back to the bagpipe bug, it makes sense to have it in the RC
14:20:26 <mlavalle> we've been fixing the same thing on the Neutron side
14:20:46 <ihrachys> right. it's just that the fix may be convoluted there.
14:20:51 <amotoki> +1. it must be fixed
14:20:58 <ihrachys> because of the ordering issue that is described in comments
14:21:10 <ihrachys> bgpvpn was caught in the middle of revert
14:21:23 <tmorin> precisely yes
14:21:27 <tmorin> (hi everyone)
14:21:30 <ihrachys> tmorin, I guess the silly question would be: can we revert yours?
14:22:15 <tmorin> ihrachys: basically, all our queens release depends on the switch to OVO, so reverting is not an option
14:22:54 <tmorin> ihrachys: but I can see if the one specific query for IPAllocation could be done with a plain SQLAlchemy query -- that would work the issue around, wouldn't it ?
14:22:57 <ihrachys> ok. I have some convoluted suggestions in mind.
14:23:02 <ihrachys> but we can discuss off base
14:23:09 <tmorin> ihrachys: wfm
14:23:33 <ihrachys> I meant off band btw
14:23:47 <ihrachys> anyway. I will reach out.
14:23:52 <mlavalle> LOL
14:24:08 <mlavalle> thanks ihrachys for helping with this
14:24:41 <mlavalle> so I think we will add it to the RC.
14:24:46 <tmorin> yes, many thanks!
14:25:21 <mlavalle> ok, done
14:25:28 <mlavalle> it is now in the RC dashboard
14:26:37 <mlavalle> any other topics related to our RC1?
14:27:11 <amotoki> one thing i would like ask your opinion. azaid asked me several times on bug 1405057
14:27:12 <openstack> bug 1405057 in neutron "Filter port-list based on security_groups associated not working" [Low,In progress] https://launchpad.net/bugs/1405057 - Assigned to Ahmed Zaid (ahmedzaid10)
14:27:27 <amotoki> it is port filtering based on SG. it is half feature.
14:28:17 <mlavalle> yeah, I have taken a look a couple of times at the patchset and given feedback
14:28:46 <mlavalle> I personally don't think it's an urgent thing to have in Queens
14:28:53 <mlavalle> what do others think?
14:29:26 <yamamoto> it doesn't seem urgent
14:29:31 <amotoki> it is cost operation filtering ports by SG, so personally it is worth having it, but I agree it is not urgent.
14:29:51 <ihrachys> wait. don't we already support this filtering? I remember smth in Port object for that that was added for agent sake to mimic previous behavior.
14:29:58 <ihrachys> regardless it's not urgent indeed
14:30:20 <slaweq> ihrachys: I did patch for OVO filtering based on SG
14:30:24 <amotoki> ihrachys: the patch depends on OVO port filtering by SG
14:30:28 <slaweq> but this is about filtering in API calls
14:30:46 <ihrachys> oh ok
14:31:10 <ihrachys> yeah I get that it's for api; what I mean is when we switch to port OVO, it should just work.
14:31:11 <slaweq> and in fact I think that this part of ML2 code is not switched to OVO yet so it makes some filters query currently
14:31:37 <amotoki> i was a bit wrong. slaweq is correct
14:32:26 <mlavalle> ok, I think we can move on and continue this piece of the conversation in gerrit
14:33:00 <ihrachys> yes
14:33:29 <amotoki> personally it is less risk from impl perspective, so I don't have any concern on this point.
14:33:32 <mlavalle> so let's go to RFEs
14:33:37 <amotoki> okay
14:33:55 <mlavalle> First one for this morning is https://bugs.launchpad.net/neutron/+bug/1715386
14:33:56 <openstack> Launchpad bug 1715386 in neutron "[RFE]Support routing traffic based on subnet" [Wishlist,In progress] - Assigned to zhaobo (zhaobo6)
14:34:54 <mlavalle> I have made 2 or 3 passes on this spec trying to help the author to clarify the use cases
14:35:05 <mlavalle> yamamoto has also provided feedback
14:36:49 <mlavalle> keep in mind that the question at this point in time is not to approve the spec. it is to see if we have enough info to mark the RFE to approved and continue refining the spec
14:40:34 <yamamoto> i wonder why the author added dest ip match in the latest version of the spec
14:41:08 <mlavalle> that probably is a consequence of a comment I made two reviews ago
14:41:45 <mlavalle> for the second use case the routing decision would need a combination of source subnet and destination
14:42:17 <mlavalle> my comment was actually: with this API can you fully support use case 2?
14:42:37 <mlavalle> the truth is I am speculating a little bit
14:44:51 <yamamoto> for the "Dst MMMM via NN"?
14:45:12 <mlavalle> yeah, I have the same question
14:45:38 <amotoki> sounds like SR
14:45:47 <mlavalle> but last night I ran out of time so didn't get to that specific
14:45:57 <mlavalle> SR = source routing?
14:46:05 <amotoki> segment routing
14:46:46 <mlavalle> it is clearly routing not based exclusively on the destination
14:52:40 <ihrachys> what's the silence about
14:53:00 <mlavalle> I was assuming folks were going over the spec
14:53:05 <mlavalle> any feedback?
14:53:24 <yamamoto> i'm still awake :-)
14:53:30 <mlavalle> LOL
14:54:39 <mlavalle> ok so maybe we are not ready to take the next step with this RFE
14:54:51 <amotoki> controlling traffic based on source/dest IP is similar to SFC and use case 2 might be achieved by SFC, but it sounds too much to use SFC only for this purpose. supporting it in router might make sense though i haven't looked thru all.
14:55:35 <amotoki> let's move on
14:55:57 <mlavalle> ok so please provide feedback in the spec
14:55:59 <yamamoto> i'm still not sure if i understand (or agree) if these complex setup described in the use case are really necessary. but i can understand source routing is convenient in some cases.
14:57:16 <mlavalle> I think we can talk about this one https://bugs.launchpad.net/neutron/+bug/1717560
14:57:17 <openstack> Launchpad bug 1717560 in neutron "[RFE] allow to have no default route in DHCP host routes" [Wishlist,Triaged]
14:57:35 <yamamoto> maybe the rfe description needs an update after feedbacks on spec?   at least "based on subnet" part
14:58:17 <mlavalle> yamamoto: can you clarify
14:58:57 <yamamoto> as it seems it's now about src/dst ip prefixes rather than subnet
14:59:06 <mlavalle> ok
14:59:45 <mlavalle> so we ran out of time
15:00:01 <yamamoto> are we waiting for armax finishing mulling?
15:00:18 <mlavalle> no, I think we can move ahead with this one
15:00:39 <yamamoto> i think it's fine to move ahead
15:00:43 <mlavalle> I just want to formalize the decision with the team
15:00:51 <mlavalle> amotoki, ihrachys?
15:01:05 <ihrachys> yes let's move to bug
15:01:19 <mlavalle> cool
15:01:33 <mlavalle> thanks for attending have a great weekend!
15:01:38 <yamamoto> thank you
15:01:45 <mlavalle> #endmeeting