22:00:05 <mlavalle> #startmeeting neutron_drivers
22:00:06 <openstack> Meeting started Thu Mar 22 22: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.
22:00:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:00:09 <openstack> The meeting name has been set to 'neutron_drivers'
22:01:24 <mlavalle> haleyb: you joining today?
22:01:39 <haleyb> mlavalle: yes, with beer in hand
22:01:47 <hongbin> o/
22:02:12 <mlavalle> welcome haleyb
22:02:23 <mlavalle> and welcome hongbin
22:02:30 <mlavalle> We have quorum
22:03:08 <mlavalle> #topic Brian Haley new member of the Drivers team
22:03:26 <yamamoto> welcome
22:03:31 <mlavalle> First of all I want to welcome Brian to the drivers team
22:03:39 <hongbin> congrat
22:03:48 <mlavalle> I think you will make great contributions to this team
22:04:12 <haleyb> good to officially be here now that i have some time to help out
22:05:06 <mlavalle> I want also to mention that ihrachys will be transitioning out of this team and Neutron in general over the next few weeks
22:05:38 <mlavalle> He has set hig sights and goals in another project out of the OpenStack community
22:06:08 <mlavalle> We thanks him for his many contributions to Neutron and wish him luck in his next challenge
22:06:40 * mlavalle know that he doesn't need any luck.... he is great regardless
22:07:25 <mlavalle> That is relevant from the point of view of the logistics of this meeting
22:07:55 <mlavalle> yamamoto: what is better for you? this time slot or Friday morning?
22:08:04 <mlavalle> well, night for you
22:08:19 <yamamoto> either fine for me
22:08:47 <mlavalle> and you haleyb?
22:09:05 <mlavalle> Remember, it has to be sustainable during standard time
22:09:42 <haleyb> mlavalle: friday is better for me, this isn't terrible, i just sometimes have conflicts
22:10:34 <mlavalle> so I will check with amotoki. If he is ok with it. we can move the meeting to Friday morning in the US / Friday night Japan
22:10:44 <mlavalle> that way we are happier
22:11:48 <haleyb> my kids thank you mlavalle :)
22:12:04 <mlavalle> with that, these are the RFEs we have to discuss today:
22:12:11 <mlavalle> #link https://bugs.launchpad.net/neutron/+bugs?field.tag=rfe-triaged
22:12:37 <mlavalle> I am going to skip the first two, since I don't think we have much to discuss around those two today
22:13:00 <mlavalle> So first one for today is https://bugs.launchpad.net/neutron/+bug/1723026
22:13:01 <openstack> Launchpad bug 1723026 in neutron "[RFE]Support get device_ids from floatingips" [Wishlist,Confirmed] - Assigned to Hongbin Lu (hongbin.lu)
22:13:50 <mlavalle> which is associated to https://bugs.launchpad.net/neutron/+bug/1754123
22:13:52 <openstack> Launchpad bug 1754123 in neutron "[RFE] Support filter with floating IP address substring" [Wishlist,New] - Assigned to Hongbin Lu (hongbin.lu)
22:14:25 <hongbin> i think those two bugs can be separated if it helps the discussion
22:14:34 <mlavalle> sure
22:15:17 <hongbin> for the first one, the requirement is to retrieve the uuid of the nova instance , with the floating ip address given
22:15:45 <hongbin> this is in the critical call path, so we want to do it in a single api call / db transation
22:17:18 <hongbin> one option is to add the device_id to the floating ip address resource, perhaps other alternatives can solve the problem as well
22:18:11 <hongbin> that is all from me as a brief introduction
22:19:08 <mlavalle> It seems a reasonable request for me
22:19:25 <mlavalle> I must say, though, that it comes from my employer
22:19:38 <haleyb> i just don't understand the mapping between the device_id and the nova uuid, but assume if i looked at the code it would all make sense
22:20:19 <mlavalle> it's like in the case of a port
22:20:49 <hongbin> yes
22:21:14 <hongbin> basically, the device_id can be set as the device_id of the associated port
22:21:53 <haleyb> next time i stack i will have to look (and go ah-ha)
22:24:00 <mlavalle> haleyb: http://paste.openstack.org/show/709080/
22:24:08 <mlavalle> for your viewing pleasure
22:24:16 <mlavalle> just created that VM for you
22:24:36 <haleyb> mlavalle: thanks, now it all makes sense :)
22:24:55 <hongbin> it worths to mentioned that amotoki left a comment in the bug report (comment #18) as a suggested amendment of the proposal
22:25:10 <hongbin> #link https://bugs.launchpad.net/neutron/+bug/1723026/comments/18
22:25:11 <openstack> Launchpad bug 1723026 in neutron "[RFE]Support get device_ids from floatingips" [Wishlist,Confirmed] - Assigned to Hongbin Lu (hongbin.lu)
22:26:22 <mlavalle> that makes sene
22:26:25 <mlavalle> sense
22:27:36 <mlavalle> so amotoki seems to be on-board with this requirement
22:29:38 <yamamoto> for you it's often known that the ip in question is a floating ip?
22:30:53 <hongbin> perhaps no, but a floatingip list call will figure it out
22:31:28 <yamamoto> so if there's "what's this ip" api, it's more convenient for you?
22:32:05 <hongbin> maybe, depending on how this api looks like
22:34:38 <mlavalle> that's an interesting idea yamamoto.... so that "what is this ip" api could answer whether the IP is fixed or floaing and provide additional the relevant information, depending of the case, including the device_id?
22:36:37 <mlavalle> and for floating ips include the port information as proposed by amotoki
22:37:10 <yamamoto> yea.  it might be a router (or something snat'ed behind it) as well.
22:37:57 <mlavalle> would that work, hongbin?
22:38:26 <yamamoto> i thought the motivation of the snat logging proposal was something similar. don't your use case need the history?
22:39:16 <hongbin> mlavalle: i am still trying to understand the advice
22:39:43 <hongbin> suppose a new api is proposed, what is the list of attributes ?
22:40:33 * hongbin am not familiar with the snat logging
22:41:06 <mlavalle> what I understood  is we could have a new resource /ip-address/{ip-address}
22:41:45 <mlavalle> when you do a GET against it, it will determine whether it {ip-address} is fixed and floating and then respond with the relevant data
22:42:07 <mlavalle> including, for floating ips, the port data that amotoki proposed
22:42:16 <mlavalle> is that your idea yamamoto?
22:42:38 <yamamoto> yes
22:42:48 <hongbin_> the key is what kind of data returned by the /ip-address endpoint
22:43:35 <mlavalle> in principle, for floating ips, the same you currently when you do GET /floting_ips + amotoki's proposal
22:44:03 <mlavalle> and for fixed IPs, ports data
22:44:14 <hongbin_> ok
22:44:51 <mlavalle> but this way, when you see "suspicious" activity in an ip address, you don't have to determine first whether it if floating or fixed
22:44:59 <mlavalle> right yamamoto?
22:45:15 <yamamoto> yes
22:45:19 <hongbin_> sounds good to me, i can communicate this with my team to get further feedback
22:45:24 <yamamoto> snat logging is this one https://bugs.launchpad.net/neutron/+bug/1752290
22:45:25 <openstack> Launchpad bug 1752290 in neutron "[RFE] (Operator-only) Add support 'snat' for loggable resource type" [Wishlist,Confirmed]
22:46:30 <mlavalle> in other words, it is a way to address the requirement that we have already in the RFE but with yamamoto's proposal, giving it a more general solution
22:47:34 <mlavalle> does it make sense?
22:47:45 <mlavalle> what do you think haleyb?
22:48:04 <yamamoto> basically they want to know which vm was using the given ip at the given time in the past. as we can re-associate floating ips, i was wondering you might need similar historical data for your purpose.
22:48:28 <mlavalle> that's also true
22:49:04 <haleyb> sorry, did not read this rfe, but do know from experience that operators want to know the timeframe an IP was being used
22:49:11 <mlavalle> that can be a second step in the implementation of this new api
22:49:36 <hongbin_> cool
22:49:57 <mlavalle> haleyb: that's a good point. that is why I say the historical data could be a second step
22:50:12 <haleyb> mlavalle: topic is still all about me btw
22:50:44 <mlavalle> #undo
22:50:45 <openstack> Removing item from minutes: #link https://bugs.launchpad.net/neutron/+bug/1723026/comments/18
22:50:58 <mlavalle> #topic RFEs
22:51:08 <mlavalle> well
22:51:10 <haleyb> it doesn't matter at this point i guess
22:51:59 <mlavalle> anyway, I think we (the Huawei guys) can ask our public cloud bretheren if the logging data is soemthing they would appreciate
22:52:29 <mlavalle> does that make sense?
22:52:39 <hongbin_> +1
22:52:43 <yamamoto> +1
22:53:12 <mlavalle> what do you think haleyb?
22:53:49 <haleyb> +1
22:53:57 <mlavalle> cool
22:54:22 <mlavalle> Next one is https://bugs.launchpad.net/neutron/+bug/1738738
22:54:23 <openstack> Launchpad bug 1738738 in neutron "[Neutron][Firewall] Extend FWaaS to provide DSCP filtering" [Wishlist,Confirmed] - Assigned to Reedip (reedip-banerjee)
22:55:04 <mlavalle> Sridark responded to our question from one of the previous meetings
22:55:43 <mlavalle> The FWaaS team feels that the API is ready for this functionality
22:55:56 <mlavalle> so I am for approving this RFE
22:58:12 <yamamoto> +1
22:59:14 <mlavalle> how about you haleyb?
23:00:06 <haleyb> +1
23:00:16 <mlavalle> ok, cool
23:00:22 <mlavalle> time's up
23:00:28 <mlavalle> #endmeeting