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