14:00:17 <mlavalle> #startmeeting neutron_drivers
14:00:18 <openstack> Meeting started Fri Mar 30 14:00:17 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:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:21 <openstack> The meeting name has been set to 'neutron_drivers'
14:00:33 <mlavalle> Hi there?
14:01:33 <amotoki> hi
14:02:05 <mlavalle> hey amotoki, how are you?
14:02:27 <amotoki> this week was busy for internal things
14:02:36 <amotoki> it is the last week of FY in Japan
14:03:07 <mlavalle> really? all Japanese companies close FY at the end of March?
14:03:24 <amotoki> yes, Apr is the start of a new FY
14:03:55 <mlavalle> so this coming Monday all Japanese corporations will start FY2019?
14:04:22 <amotoki> it's the start of FY2018 not FY2019
14:04:32 <mlavalle> ahhhh!
14:05:12 <mlavalle> I was with HP many years.... They started their FY2019 on October 1st of 2018. That is why I had the wrong idea for Japan
14:05:15 <amotoki> we don't call it FY2018/19 as seasons of sports
14:05:37 <amotoki> ah I see.
14:06:55 <amotoki> how about huawei? when it starts?
14:06:59 <mlavalle> so haleyb and all the RH guys have a Holiday today (Good Friday) so if yamamoto doesn't show up, we won't have quorum
14:07:13 <mlavalle> let's wait for a few minutes
14:08:46 <mlavalle> in the meantime, let me ask you a question. Now that haleyb is the new memeber of the drivers team, the meeting at this time is more convenient for him. Would you be ok if we stop alternating and have all the meetings in this time slot?
14:09:29 <amotoki> mlavalle: I am okay with this time slot.
14:10:08 <mlavalle> ok, so if the meeting room is available, I will remove the alternate time slot
14:10:22 <yamamoto> hi, sorry for being late
14:10:25 <amotoki> at first I was afraid of my presence this time due to Friday night, but I have most events in other days
14:10:38 <mlavalle> perfect!
14:11:10 <amotoki> yamamoto: welcome
14:11:16 <mlavalle> yamamoto: your timing was perfect. You gave me the opportunity to ask amotoki about having all the meetings in this time slot
14:11:41 <mlavalle> we were just finishing that topic when you showed up
14:11:52 <mlavalle> so it was like you read our minds ;-)
14:12:01 <mlavalle> welcome!
14:12:10 <amotoki> :)
14:12:33 <yamamoto> have you submitted irc-meetings patch?
14:12:53 <mlavalle> no, I wanted to ask amotoki first. I will submit it after the meeting today
14:13:29 <amotoki> Looking at the meeting calendar, this slot next week is not filled
14:14:04 <mlavalle> there you go. I'll submit the patch in a bit and will add you to the review line so you can +1 it
14:14:57 <mlavalle> so let's get going then
14:15:08 <mlavalle> The RFEs to discuss today are here:
14:15:17 <mlavalle> #link https://bugs.launchpad.net/neutron/+bugs?field.tag=rfe-triaged
14:15:56 <mlavalle> First one is https://bugs.launchpad.net/neutron/+bug/1723026
14:15:57 <openstack> Launchpad bug 1723026 in neutron "[RFE]Support get device_ids from floatingips" [Wishlist,Confirmed] - Assigned to Hongbin Lu (hongbin.lu)
14:16:23 <mlavalle> we had a great suggestion from yamamoto last week about this RFE
14:17:00 <mlavalle> I know hongbin sent an internal email in our mutual employer asking for feedback
14:17:13 <mlavalle> we got some good response
14:17:32 <mlavalle> but we are still waiting to hear from other key people
14:17:49 <mlavalle> and I don't see any additional input in the RFE itself
14:17:58 <mlavalle> so, let's skip for next week
14:18:21 <amotoki> is this about a new resource /ip-address?
14:18:28 <mlavalle> yes
14:18:33 <amotoki> I am reading the log last week
14:18:44 <mlavalle> any thoughts on that?
14:19:24 <amotoki> let me comment about it later or next week
14:19:55 <mlavalle> Great, looking forward to your input :-)
14:20:51 <mlavalle> Next one is https://bugs.launchpad.net/neutron/+bug/1743480
14:20:52 <openstack> Launchpad bug 1743480 in neutron "[RFE] No way to differentiate beween floating IP networks and external provider networks" [Wishlist,Confirmed]
14:21:32 <mlavalle> For this one, amotoki provided a comment on March 16th with guidance to the submitter
14:21:51 <mlavalle> I complmented a few days later with what I see in my development system
14:22:03 <mlavalle> we haven't heard back from the submitter since
14:22:11 <amotoki> yes.
14:22:12 <amotoki> I first would like to confirm my understanding is same as yours.
14:22:23 <amotoki> are we in the same page?
14:22:47 <mlavalle> Yes, that has been my understanding
14:23:36 <amotoki> it seems the submitter misunderstands the meaning of the attributes and he has its own interpretation of these attributes.
14:23:56 <mlavalle> Yes
14:24:27 <amotoki> once his misunderstanding is clarified we can update our API reference.
14:24:48 <mlavalle> unless he can show us that with this understanding (ours), he cannot address his situation
14:25:18 <mlavalle> but at this point, I totally agree with you amotoki
14:26:16 <amotoki> I will post a comment as follow-up of his comment #20 (reply to my comment) after the meeting to encourage more feedback
14:26:18 <mlavalle> so let's give him another week to respond back. If by then we don't hear from him, we will deem the RFE addressed and we can update our API ref
14:26:32 <mlavalle> amotoki: that sound good!
14:27:54 <mlavalle> Next one is https://bugs.launchpad.net/neutron/+bug/1745192
14:27:56 <openstack> Launchpad bug 1745192 in neutron "Can't create a vlan transparent network in mixed driver environment" [Wishlist,Confirmed]
14:31:00 <amotoki> theoretically what we need to check is whether all drives involved in port binding support a specific extension.
14:32:14 <amotoki> if both ovs and cisco drivers (borrowed from the bug report) are in hierarchical binding, we need to check both, but if one of them are involved, we should allow vlan-transparent.
14:32:52 <mlavalle> correct
14:33:10 <yamamoto> a question is how to report a failure to users
14:33:48 <mlavalle> it is only in a HPB situation that both drivers have to suppprt the feature
14:35:34 <amotoki> what kind of errors does nova report when port binding failure happens?
14:35:53 <amotoki> Does a corresponding VM fail to launch?
14:36:35 <mlavalle> Yes, I think it will fail
14:37:54 <amotoki> yamamoto: isn't vm launch failure enough?
14:38:34 <amotoki> when a port is created, the port is not bound so in my understanding we cannot determine the port can be bound in the current impl.
14:39:22 <mlavalle> right, Nova creates the ports unbound
14:39:27 <yamamoto> i guess it's ok if a user doesn't need to dig into ml2 logs to see why it failed.
14:39:44 <mlavalle> and then, at some point it updates it with the binding: https://github.com/openstack/nova/blob/master/nova/network/neutronv2/api.py#L2561
14:40:04 <amotoki> there might be a room to improve nova error message around port binding failure.
14:41:06 <mlavalle> how do we address that?
14:41:29 <mlavalle> or even confirm it
14:43:03 <mlavalle> I think it is unlikely this execption will bubble up raw all the way to the API: https://github.com/openstack/nova/blob/master/nova/network/neutronv2/api.py#L2622
14:43:11 <amotoki> as RFE i think it is reasonable, but I am not clear yet how we can address it. do you think iti is staright-forward?
14:44:38 <mlavalle> so I think we can easily address it in the drivers manager code
14:45:13 <amotoki> nice
14:45:30 <mlavalle> but yes, maybe there are error reporting considerations
14:46:30 <amotoki> I am fine to move this forward. we seem to improve error reporting including nova API layer as we discussed
14:47:29 <amotoki> s/nova API layer/nova neutron API wrapper/
14:48:22 <yamamoto> i'm fine to approve this. there might be a room to improve error reporting but it is somehow independent from the rfe.
14:48:24 <mlavalle> This is the piece of code involved in the drivers manager: https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/managers.py#L395
14:49:30 <amotoki> i am looking at the same place :)
14:49:38 <mlavalle> LOL
14:50:01 <mlavalle> ok, let's move it forward then
14:50:17 * mlavalle changing tags
14:52:33 <mlavalle> Left a comment about our discussion concern for error reporting to the user
14:53:08 <amotoki> thanks, nice comment!
14:53:49 <mlavalle> Next one is https://bugs.launchpad.net/neutron/+bug/1748132
14:53:50 <openstack> Launchpad bug 1748132 in neutron "[RFE] Can not create router gateway without external_fixed_ips" [Wishlist,In progress] - Assigned to Guoshuai Li (liguoshuai1990)
14:54:23 <mlavalle> For this one we mostly agree to approve the submitter's original proposal two meetings ago
14:54:49 <mlavalle> But I think amotoki mentioned we wanted to post some comments
14:54:57 <mlavalle> is my recollection correct?
14:55:05 <mlavalle> he wanted^^^^
14:56:10 <amotoki> my understanding is same
14:56:18 <yamamoto> my memory is dim as always
14:56:43 <amotoki> we discussed two points: saving IP as operators and how operators can enforce it to users.
14:56:51 <mlavalle> correct
14:57:14 <mlavalle> and I think you wanted to comment on the tension between those two view points
14:58:19 <amotoki> yes
14:58:50 <mlavalle> since we are running out of time, I will let you post your comments and we'll go from there
14:59:01 <amotoki> i will post a follow-up comment after checking the discussion. your comments would be appreciated too.
14:59:02 <mlavalle> you ok with it?
14:59:19 <mlavalle> will follow up myself
14:59:26 <mlavalle> Thanks for attending guys
14:59:38 <amotoki> three TODOs  from the meeting > amotoki
14:59:39 <mlavalle> Have a great weekend and happy new fiscal year
14:59:48 <amotoki> :)
14:59:48 <yamamoto> btw, i'll be away for Apr 9 week
14:59:59 <mlavalle> yamamoto: ack
15:00:06 <mlavalle> #endmeeting