22:00:43 <mlavalle> #startmeeting neutron_drivers
22:00:44 <openstack> Meeting started Thu Mar  8 22:00:43 2018 UTC and is due to finish in 60 minutes.  The chair is mlavalle. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:00:45 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:00:47 <openstack> The meeting name has been set to 'neutron_drivers'
22:00:57 <yamamoto> hi
22:00:58 <mlavalle> hi there!
22:01:08 <doude> hi
22:01:16 <mlavalle> yamamoto: how was your trip back from Dublin?
22:01:16 <SridarK> hi
22:01:30 <mlavalle> did you get stuck in Dublin?
22:01:44 <mlavalle> hi SridarK, doude
22:02:09 <yamamoto> everything was mostly on time
22:02:36 <mlavalle> great, amotoki was stranded until Tuesday morning
22:02:55 <yamamoto> i guess he enjoyed it
22:03:00 <mlavalle> he did
22:03:50 <mlavalle> SridarK, doude: is there a topic you want to bring up in this meeting?
22:04:07 <SridarK> mlavalle: yes doude has a FWaaS related RFE
22:04:32 <mlavalle> doude: what is the RFE?
22:04:46 <doude> yes mlavalle, a bug I tagged as RFE for FWaaS
22:04:57 <doude> https://bugs.launchpad.net/neutron/+bug/1702312
22:04:59 <openstack> Launchpad bug 1702312 in neutron "[RFE][FWaaS v2] Does not work with core plugin non based on Neutron DB model" [Undecided,New]
22:05:31 <doude> it's about re-work FW service plugin to allow pluggable backend
22:05:56 <doude> like it's done for other services like BGPVPN or LBaaS
22:06:43 <SridarK> mlavalle: doude has had a patch out for review as well - but with our priorities for L2 support we were a bit late to make it into Queens
22:07:13 <doude> yes https://review.openstack.org/#/c/480265/
22:07:16 <mlavalle> SridarK: is this something that the FWaaS team wants / can support?
22:07:33 <SridarK> Also we realized that we did not have a RFE filed so we want to follow process
22:07:42 <doude> patch is big but it is mostly file renaming
22:07:45 <SridarK> mlavalle: yes we will support it
22:08:28 <mlavalle> in that case I don't have a problem approving it
22:08:34 <mlavalle> yamamoto: any concerns?
22:08:39 <SridarK> mlavalle: And we have discussed it in our meetngs extensively also
22:09:55 <yamamoto> is it about db models of fwaas itself?
22:10:19 <doude> no it does not touch the db model
22:10:37 <doude> just decouple it from the service plugin and driver
22:11:19 <doude> to allow new drivers not based on the DB model
22:11:21 <doude> https://docs.google.com/presentation/d/1_9KkNgIbWYE6tucoym8N7J2xfcQ1XwN8Zuu-ALEUD3U/edit#slide=id.g27fa2ac987_0_0
22:11:44 <yamamoto> not based on the fwaas db models right?
22:11:50 <doude> I tried to describe that in that diagrams --^
22:11:54 <yamamoto> vs neutron etc
22:11:58 <doude> yes
22:12:23 <doude> or new driver based on the DB model but which not used the RPC agent mechanism
22:14:01 <yamamoto> you mean the last page of the doc?
22:14:56 <doude> yes finally we prefer solution on slide 4
22:15:27 <mlavalle> so ignore slide 3?
22:15:55 <doude> which proposes 2 interface, one for driver not based on the Neutron DB model, and another one which maintain DB transaction
22:16:29 <mlavalle> and branch on the right is what is currently implemented, right?
22:16:30 <doude> the actual FWaaS implementation is based on the second interface and adds all agent RPC stuff
22:16:31 <yamamoto> i'm not sure how it's better than having a separate service plugin for contrail (with possible refactoring to share code)
22:16:38 <doude> yes mlavalle ignore 3
22:16:47 <yamamoto> but if fwaas team is fine with it, i have no problem with it.
22:17:12 <doude> yes mlavalle branch on the right is the actual implem
22:17:49 <doude> IMO, that permits to factorize some code like checks and validation
22:17:58 <SridarK> yamamoto: yes sometime in I or J release we talked abt this but we never did - so we are ok
22:18:24 <doude> and we can also imagine mixed drivers
22:18:49 <mlavalle> SridarK: do me a favor. Please indicate in the RFE that the FWaaS team wants to pursue this RFE. Include the pointer to the Google presentation. As soon as that is done, I'll move it approved
22:19:03 <SridarK> mlavalle: ok will do
22:19:20 <mlavalle> SridarK, doude: thanks for bringing this up
22:19:21 <yamamoto> doude: you mean contrail + something other which doesn't use db either?
22:19:26 <mlavalle> and good luck with the review
22:19:36 <doude> thanks mlavalle
22:19:42 <mlavalle> seems like a big patch to me
22:19:55 <yamamoto> big patch but mostly mechanical it seems
22:20:06 <doude> yes yamamoto but not sure it's realistic
22:20:49 <mlavalle> doude: will this approach be usable by other plugins that are not Contrail?
22:21:06 <doude> yes it is
22:21:11 <mlavalle> cool
22:21:19 <mlavalle> thanks
22:21:23 <SridarK> mlavalle: done added comments
22:21:43 <SridarK> mlavalle: yamamoto: we have discussed breaking up the patch as well
22:22:13 <mlavalle> SridarK, doude: I just marked it approved
22:22:15 <SridarK> for easier review but as stated yes mostly mechanical
22:22:24 <SridarK> mlavalle: yamamoto: thanks
22:22:34 <doude> thanks
22:23:34 <yamamoto> it's for contrail monolithic plugin, not contrail ml2 driver, right?
22:23:49 <yamamoto> (just curious)
22:24:23 <doude> yes it is yamamoto
22:24:25 <mlavalle> yamamoto: yeah it is the monlithic plugin
22:24:36 <mlavalle> otherwise it would use the DB
22:24:54 <yamamoto> i got it, thank you
22:25:03 <doude> but the ML2 plugin will also benefit to that patch because it will have to use the DB interface
22:25:29 <doude> like the FirewallAgentDriver
22:26:12 <doude> we did the same work on the BGPVPN service plugin
22:26:28 <doude> I mostly copy the idea here
22:26:40 <mlavalle> yamamoto: we don't have quorum. it seems amotoki is too tired after all the fun he had in Dublin
22:26:49 <mlavalle> doude: cool, the approach is tested
22:27:16 <mlavalle> yamamoto: but have you seen https://bugs.launchpad.net/neutron/+bug/1743480?
22:27:18 <openstack> Launchpad bug 1743480 in neutron "[RFE] No way to differentiate beween floating IP networks and external provider networks" [Wishlist,Confirmed]
22:27:27 <mlavalle> what are your thoughts on that one?
22:27:31 <yamamoto> i guess we went to ops meeting after that (2 days event in tokyo)
22:27:47 <yamamoto> even more tired
22:28:42 <mlavalle> ahhh, yeah, smcginnis was there, right?
22:28:57 <yamamoto> i don't know. i wasn't there
22:29:01 <mlavalle> ok
22:29:23 <yamamoto> i'm not sure about the use case.  wondering if auto-fip fits it.
22:30:20 <mlavalle> but he has a point, doesn't he?
22:30:27 <yamamoto> after all it seems what they want is a marker for the network which is the default for floating ips
22:31:05 <yamamoto> yea, i agree there's no suitable mechanism for them right now
22:31:23 * smcginnis waves from Tokyo
22:31:45 <mlavalle> the network can have router:external=True and still not be suitable for fips, correct?
22:31:51 <yamamoto> yes
22:32:02 <mlavalle> hey smcginnis hope I didn't wake you up
22:32:02 <yamamoto> smcginnis: hi!
22:32:34 <smcginnis> Nope, just getting up and checking in and happened to see your comment. ;)
22:39:51 <mlavalle> yamamoto: thanks for showing up and your comments
22:39:59 <yamamoto> my understading of the situation is 1. they want to mark some networks for fip allocations 2. gman already has "default" attribute for a similar purpose 3. auto-fip might or might not use the "default" attribute
22:40:30 <mlavalle> gman?
22:40:41 <yamamoto> i wonder if we can avoid having a lot of similar default-for-xxx attributes :-)
22:40:52 <yamamoto> get me a network
22:40:57 <mlavalle> ahhh
22:41:03 <yamamoto> auto-allocated-topology
22:41:09 <mlavalle> yeah
22:42:19 <mlavalle> and yes, I agree, about the default-for-xxx attributes
22:43:08 <mlavalle> yamamoto: closing the meeting now
22:43:14 <yamamoto> sure
22:43:16 <mlavalle> thanks for the attendance
22:43:18 <yamamoto> thank you
22:43:25 <mlavalle> #endmeeting