14:00:12 <mlavalle> #startmeeting neutron_drivers
14:00:13 <openstack> Meeting started Fri Jan 19 14:00:12 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:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:17 <openstack> The meeting name has been set to 'neutron_drivers'
14:00:28 <yamamoto> hi
14:00:43 <mlavalle> hey yamamoto. how are you?
14:00:53 <yamamoto> i'm fine
14:01:08 <mlavalle> are you going to Dublin?
14:01:14 <yamamoto> yes
14:01:20 <mlavalle> \o/
14:01:32 <haleyb> o/
14:01:43 <mlavalle> hey haleyb
14:02:09 <haleyb> hey mlavalle, i'm ready for work :)
14:02:36 <mlavalle> let's wait 1 minute for amotoki
14:04:56 <ihrachys> o/ sorry for being late
14:05:27 <mlavalle> ihrachys: no problem
14:05:36 <mlavalle> nice to see you
14:05:46 <mlavalle> we have quorum now
14:06:35 <mlavalle> First one for today is https://bugs.launchpad.net/neutron/+bug/1701413
14:06:36 <openstack> Launchpad bug 1701413 in neutron "Vpnaas VPN ikepolicy does not support aggressive mode" [Wishlist,Triaged] - Assigned to zhichao zhu (rtmdk)
14:08:22 <ihrachys> mlavalle, seems straightforward though I admit I don't grasp all intricacies of those modes.
14:08:37 <ihrachys> as long as it has a flag extension to discover the feature, it should be fine.
14:09:07 <mlavalle> yeah, if I understand correctly is an API change, right?
14:09:39 <yamamoto> it allows a new value for the existing field
14:09:51 <yamamoto> so API change, yes
14:10:18 <mlavalle> so yeah, as long as it is discoverable, I think it is fine
14:10:48 <mlavalle> so I am + for it
14:10:55 <mlavalle> how about the otheres?
14:11:00 <mlavalle> others
14:11:07 <yamamoto> i think it's fine
14:11:14 <mlavalle> cool
14:11:17 <ihrachys> I am fine with it
14:11:43 <mlavalle> I am going to indicate in the RFE the need for this to be discoverable as an API extension
14:13:11 <mlavalle> Done
14:13:36 <mlavalle> Next one is https://bugs.launchpad.net/neutron/+bug/1715386
14:13:38 <openstack> Launchpad bug 1715386 in neutron "[RFE]Support routing traffic based on subnet" [Wishlist,Triaged] - Assigned to zhaobo (zhaobo6)
14:14:00 <mlavalle> I have to confess that I didn't have time to read the latest revision of the spec
14:15:47 <ihrachys> same here. maybe we should take it as homework again and discuss the next time.
14:16:21 <yamamoto> and/or discuss on gerrit
14:16:44 <mlavalle> ihrachys: agree. I'll read it at the end of this meeting and leave my comments
14:17:12 <mlavalle> Next one is https://bugs.launchpad.net/neutron/+bug/1717560
14:17:13 <openstack> Launchpad bug 1717560 in neutron "[RFE] allow to have no default route in DHCP host routes" [Wishlist,Triaged]
14:18:45 <mlavalle> Progress was made on this one over the past couple of weeks
14:20:05 <ihrachys> seems like we can achieve that without api change
14:20:39 <haleyb> and just fix a but in how we build the opts file
14:20:44 <haleyb> s/but/bug
14:21:01 <ihrachys> if that's the case, it's great. plugins may need to adopt to whatever test case we come up with for the 'feature' but since api layer already allows empty value, it can be looked at as a bug.
14:22:03 <mlavalle> would it need adjustment to the client as well?
14:22:30 <mlavalle> "we'll have to be careful as whether to do that only when the option is None and not when it is an empty string"
14:23:33 <ihrachys> I don't think anything is needed. looks like Thomas could easily create the option with existing clients.
14:23:44 <ihrachys> not sure how you can pass None via json
14:24:10 <haleyb> does None vs '' just need clarification in the api?
14:24:17 <ihrachys> oh I guess it's null
14:24:46 <ihrachys> I would expect None to behave the same way as empty in this case
14:24:49 <mlavalle> In reading what he wrote, I thought he had edited the dnsmasq opts file manually, but I might be wrong
14:25:20 <haleyb> mlavalle: he had to edit to fix the trailing comma
14:25:28 <ihrachys> no I mean on api side, he was able to create the option
14:25:40 <mlavalle> yeah
14:25:42 <ihrachys> which then triggered the bug in dnsmasq code, that he worked around by editing
14:25:56 <mlavalle> ok
14:27:24 <mlavalle> so I am going to ask the question in the RFE if fixing that piece of code would be sufficient and based on the answer convert this to a bug
14:27:28 <mlavalle> makes sense?
14:27:42 <yamamoto> yes
14:28:23 <ihrachys> yes
14:29:08 <mlavalle> Done
14:29:45 <mlavalle> Next one for today is https://bugs.launchpad.net/neutron/+bug/1720727
14:29:46 <openstack> Launchpad bug 1720727 in neutron "[RFE] (Operator-only) Extend logging feature to support for FWaaS v2" [Wishlist,Triaged]
14:31:17 <ihrachys> so it's a new resource_type?
14:32:03 <yamamoto> yes
14:32:11 <yamamoto> i wonder what's the status of fwaas v2
14:32:46 <yamamoto> ie. if it's ready to add extra features
14:33:04 <ihrachys> yeah, at the end of the day we should seek their guidance on this one
14:33:43 <mlavalle> During the Neutron meeting this week, xgerman said FWaaS V2 is ready for Queens
14:34:07 <mlavalle> but yeah, we should get their input on this one
14:34:40 <mlavalle> I can take the action item to talk to Sridark and Xgerman and get them to provide input in the RFE
14:34:41 <ihrachys> I would imagine fwaasv2 has multiple resources. a bit of clarification on what's the expected expansion of api would help to judge.
14:34:54 <ihrachys> as it stands, the RFE is not too informative
14:35:01 <mlavalle> agree
14:35:27 <mlavalle> and get input from the FWaaS team
14:35:57 <mlavalle> #action mlavalle to ask FWaaS team to provide input on this RFE
14:36:02 <mlavalle> Makes sense?
14:36:02 <yamamoto> the implementation might be tricky as fwaas is "out of tree" and log plugin is in tree. maybe it needs some kind of registration api like quotas?
14:36:25 <mlavalle> good point
14:36:38 <ihrachys> yamamoto, at the end of the day, it's just a logging resource that you can fetch from db / get via rpc ...
14:37:11 <ihrachys> as long as resource_type allows the new value, it should work without registration no?
14:37:45 <yamamoto> it might be.
14:38:29 <mlavalle> I think that will be the case as well
14:38:39 <ihrachys> I think we can handle that either way. let's reach out to fwaas / clarify the proposal first.
14:38:46 <yamamoto> i suppose sometimes logging resource changes need to propagate to fwaas right?
14:38:51 <mlavalle> But this is something we can get clarified with additional detail in the RFE
14:39:32 <yamamoto> sure
14:40:13 <mlavalle> I will request further detail in the RFE along these lines
14:40:18 <ihrachys> yamamoto, we have callbacks to propagate
14:41:41 <mlavalle> ok, let's seek further input as mentioned above
14:42:32 <yamamoto> ihrachys: right. but i suspect it involves something more, given the structure of the current logapi drivers
14:42:34 <mlavalle> and we reached the end of our list for today
14:43:25 <ihrachys> mlavalle, nothing to discuss?
14:43:47 <mlavalle> I don't have anythin else to discuss today
14:43:57 <yamamoto> a sec
14:44:00 <mlavalle> do folks have things to bring up to the team?
14:44:19 <yamamoto> what to do for this?  https://review.openstack.org/#/c/528189/
14:44:20 <patchbot> patch 528189 - neutron - Introduce rfe-confirmed and rfe-triaged tags
14:45:12 <mlavalle> I am for W+ it
14:45:21 <mlavalle> what do you think ihrachys?
14:45:47 <ihrachys> I haven't read the proposal but yes, gerrit sucks so it makes sense on first sight
14:45:52 <ihrachys> I will review it after the meeting
14:46:09 <ihrachys> maybe I can +w it after I read it through
14:46:12 <mlavalle> ihrachys: if you are ok with it, please just W+ it
14:46:17 <ihrachys> ok
14:46:48 <mlavalle> thanks yamamoto for working on it
14:47:13 <yamamoto> np. it was for my own convenience.
14:47:36 <mlavalle> it is for the convinience of the entire team :-)
14:47:54 <mlavalle> Ok team, have a very nice weekend!
14:48:04 <mlavalle> #endmeeting