14:01:04 <slaweq> #startmeeting neutron_drivers 14:01:05 <openstack> Meeting started Fri Nov 15 14:01:04 2019 UTC and is due to finish in 60 minutes. The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:01:08 <openstack> The meeting name has been set to 'neutron_drivers' 14:01:17 <yamamoto_> hi 14:01:22 <mlavalle> o/ 14:01:33 <slaweq> welcome back aftet the PTG :) 14:01:47 <slaweq> I hope You all recovered after travels already 14:02:53 <slaweq> lets wait few more minutes for amotoki 14:03:06 <slaweq> as haleyb probably will not join today as he is still traveling IIRC 14:03:13 <amotoki> hi 14:03:17 <ralonsoh> hi 14:03:17 <slaweq> hi amotoki 14:03:24 <slaweq> welcome ralonsoh :) 14:03:28 <slaweq> ok, lets start 14:03:36 <slaweq> #topic RFEs 14:03:47 <slaweq> I have few rfe to talk about for today 14:03:50 <slaweq> first one is 14:03:52 <slaweq> https://bugs.launchpad.net/neutron/+bug/1841067 14:03:52 <openstack> Launchpad bug 1841067 in neutron "[RFE] SR-IOV agent depends on mac addresses for getting bound ports" [Medium,Confirmed] 14:04:12 <slaweq> I know that ralonsoh was checking this as our sr-iov expert 14:04:26 <slaweq> and also I hope that adrianc is around to talk about it 14:04:29 <ralonsoh> I don;t know id adrianc 14:04:36 <ralonsoh> yes, he is here 14:04:52 <ralonsoh> anyway, https://review.opendev.org/#/c/677095 can be merged 14:05:07 <ralonsoh> with the release note saying that kernels <3.13 will have problems 14:05:21 <ralonsoh> this is happening in older versions of CentOS 14:05:36 <ralonsoh> and then we should retake again https://review.opendev.org/#/c/676713 14:06:10 <ralonsoh> that's all from my side 14:06:58 <ralonsoh> (last commit will get rid of the need of using the administrative MAC, actually the goal of the bug) 14:08:37 <ralonsoh> sorry, any question? 14:10:07 <slaweq> tbh I'm not exactly sure what changes are needed for this rfe exactly, but I have no experience with sr-iov so that's probably why I don't know it :/ 14:10:30 <slaweq> I understand need of https://review.opendev.org/#/c/677095 and why we can it merge now 14:10:37 <slaweq> (actually I just approved it) 14:10:41 <ralonsoh> yes, in a couple of sentences 14:11:21 <ralonsoh> in https://review.opendev.org/#/c/676713, instead of retrieving the MAC address set by the PF, use the address set in the macvtap device 14:11:28 <ralonsoh> (well, one sentece) 14:11:47 <ralonsoh> as the commit message says 14:11:49 <ralonsoh> "This commit rids sriov agent from depending on hypervisor/nova 14:11:49 <ralonsoh> to set both administrative and effective mac for macvtap ports." 14:11:56 <slaweq> ok, and whole rfe is about that, correct? 14:12:02 <ralonsoh> exactly 14:12:18 <ralonsoh> so the first patch is just step 1 14:12:27 <amotoki> you two are faster than me. that's what I would like to ask :) 14:12:40 <slaweq> amotoki: :) sorry 14:12:45 <amotoki> np 14:13:21 <slaweq> ok, so this is "agent's side only" change, right 14:13:26 <ralonsoh> yes 14:13:36 <slaweq> and the problem with this was that it can't run on older kernels in fact 14:13:46 <slaweq> but now we don't have this blocker anymore 14:13:48 <slaweq> correct? 14:14:20 <ralonsoh> I think that older versions of CentOS still have this kernel 14:14:34 <ralonsoh> but I don;t know in this cycle (U) 14:14:50 <slaweq> in U cycle we should support Centos 8, not 7 14:14:58 <ralonsoh> oooook, so perfect 14:15:00 <slaweq> according to TC guidance 14:15:08 <ralonsoh> (do you have the link?) 14:15:11 <ralonsoh> (I lost it) 14:15:21 <amotoki> is there any place where we declare what versions of linux kernel are required? sanity check? 14:15:33 <slaweq> https://governance.openstack.org/tc/reference/project-testing-interface.html#linux-distributions 14:16:04 <ralonsoh> amotoki, not in Neutron 14:16:11 <slaweq> amotoki: no 14:16:17 <ralonsoh> and I don't know in other projects 14:16:46 <ralonsoh> I think this is something to be considered by the administrator installing OpenStack 14:17:36 <amotoki> the sanity checks check some of our dependencies... but I think it just covers some 14:17:40 <slaweq> so we can have maybe upgrade check added for it - if sr-iov agent is there, warn about min kernel version required 14:18:08 <slaweq> just to be sure that administrator is aware of it 14:18:18 <ralonsoh> slaweq, this should be done in the related patch https://review.opendev.org/#/c/677095/ 14:18:27 <ralonsoh> or in a follow-up one? 14:18:37 <slaweq> ralonsoh: can be in follow up IMO 14:18:42 <ralonsoh> perfect 14:19:00 <amotoki> sounds good 14:19:14 <ralonsoh> (I'll add a comment in the bug now) 14:19:52 <slaweq> ralonsoh: thx 14:19:52 <amotoki> I am not against the RFE approval. I am just trying to clarify it from POV of operators. 14:21:02 <slaweq> for me this rfe is fine, according to project-testing-interface document we should support only "Latest CentOS Major" release, and that is actually version 8 14:21:20 <slaweq> also Ubuntu and openSUSE has got already kernel new enough for sure 14:21:32 <ralonsoh> yes, but not CentOS 14:21:45 <ralonsoh> that's why an upgrade check and warning is needed 14:21:47 <slaweq> ralonsoh: centos 8 has got newer kernel also 14:21:58 <mlavalle> but Centos 8 foes, right? 14:22:00 <ralonsoh> yes I mean in previous versions 14:22:03 <ralonsoh> mlavalle, yes 14:22:07 <mlavalle> does^^^ 14:22:14 <slaweq> but just to be fair with operators we should add warning in release note and/or upgrade check 14:22:32 <slaweq> that's at least my opinion about this rfe 14:22:42 <mlavalle> I agree 14:23:37 <amotoki> +1 14:23:40 <ralonsoh> +1 14:23:50 <yamamoto_> +1 14:24:19 <slaweq> ok, so I will approve this rfe with comment about warnings 14:24:24 <slaweq> thx 14:24:57 <slaweq> ok, lets move on 14:24:59 <slaweq> next one 14:25:01 <slaweq> https://bugs.launchpad.net/neutron/+bug/1850818 14:25:01 <openstack> Launchpad bug 1850818 in neutron "[RFE][floatingip port_forwarding] Add description field" [Undecided,In progress] - Assigned to Pedro Henrique Pereira Martins (pedrohpmartins) 14:25:21 <mlavalle> I read this one last night 14:25:27 <mlavalle> it makes sense to me 14:25:32 <slaweq> for me too 14:25:49 <slaweq> it seems like pretty straightforward for me 14:25:50 <ralonsoh> yes and the n-lib patch is in good shape too https://review.opendev.org/#/c/692580/ 14:25:59 <slaweq> but it's API change so we need to discuss it here 14:26:06 <ralonsoh> for sure 14:26:27 <amotoki> it makes sense to me too. 14:26:34 <slaweq> IIRC liuyulong also spoke about adding name field as well to the port forwarding 14:26:51 <slaweq> to make it easier to sort/filter and so on 14:27:02 <slaweq> but he didn't mention it in comments to RFE 14:27:35 <ralonsoh> we can save time and extensions if we merge both... 14:27:47 <ralonsoh> is this acceptable? 14:27:58 <amotoki> we already have 'description' field for many resources. it is fair enough. 14:27:59 <mlavalle> I think so 14:28:10 <amotoki> regarding 'name' field, the floating IP resource has no 'name' field 14:28:24 <amotoki> so I think we can add 'description' field only. 14:28:38 <slaweq> amotoki: makes sense for me 14:29:11 <slaweq> original rfe is only about adding description so we can go with this simply 14:29:21 <ralonsoh> perfect 14:29:21 <amotoki> +1 14:29:23 <ralonsoh> +1 14:29:42 <yamamoto_> +1 14:29:55 <slaweq> +1 14:31:05 <slaweq> thx, so I will approve this rfe after the meeting 14:31:10 <slaweq> that's fast today :) 14:31:12 <slaweq> next one 14:31:24 <slaweq> https://bugs.launchpad.net/neutron/+bug/1847068 14:31:24 <openstack> Launchpad bug 1847068 in neutron "[RFE] create option in neutron.conf to disable designate+neutron consistency" [Wishlist,New] - Assigned to Gregoire Mahe (gregoiremahe) 14:31:34 <slaweq> this one we already discussed some time ago 14:31:47 <slaweq> it was proposed by Gregoire from OVH 14:32:13 <slaweq> please check last comment in this rfe 14:32:36 <slaweq> there is explained use case which they are trying to solve with this proposal 14:33:31 <mlavalle> to me it continues looking as a very spcific thing for OVH 14:33:47 <mlavalle> the way they are rolling their offering out 14:34:20 <slaweq> mlavalle: that's exactly what I wanted to say 14:34:29 <mlavalle> why don't they do their private implementation? 14:34:30 <slaweq> but I didn't want to be first ;) 14:34:54 <slaweq> they have need to test designate in production without hurting other services 14:35:00 <slaweq> and that's why they need new driver 14:35:09 <slaweq> IMO it shouldn't be in neutron tree 14:35:21 <mlavalle> DNS integration was implemented with an open driver interface 14:35:42 <mlavalle> so they have all they need to create their own private implementation 14:35:51 <amotoki> Do we already support a way to add designate to existing deployments and does it work well? this is what I am not sure. 14:36:32 <mlavalle> my employer did and works fine 14:37:11 <amotoki> good to hear that :) 14:37:38 <mlavalle> I know Rackspace did the same in their private cloud offering 14:37:48 <mlavalle> because a year ago I helped them to test it 14:38:02 <mlavalle> and haven't heard of any other issues since 14:40:56 <amotoki> so, when some failure in a record creation happens in designate side, what we see is just an inconsistency between neutron and desginate and we can still delete a neutron port, right? 14:41:17 <mlavalle> yes 14:41:38 <slaweq> amotoki: that's correct 14:42:46 <amotoki> thanks, so I think the last portion is what an user can do when an inconsistency happens between neutron and designate. 14:44:15 <amotoki> a failure can happen regardless of that designate is in production or not. 14:44:29 <slaweq> amotoki: that's true 14:44:43 <amotoki> if an inconsistency happens, should a user re-create a port? 14:45:02 <slaweq> so currently, if designate will fail during port creation user will have port created but without dns entry for it 14:45:22 <slaweq> so my understanding is that he would need to create dns entry manually in designate than 14:45:28 <amotoki> but I am afraid I am asking another problem..... the RFE requests a way to disable consistency between desginate and neutron. 14:45:28 <slaweq> mlavalle: is that correct? 14:45:47 <mlavalle> yeah, that could be an approach 14:46:22 <slaweq> but as amotoki said, it's different problem which is raised in bug https://bugs.launchpad.net/neutron/+bug/1846703 14:46:22 <openstack> Launchpad bug 1846703 in neutron "Avoid neutron to return error 500 when deleting port if designate is down" [Medium,Confirmed] - Assigned to Gregoire Mahe (gregoiremahe) 14:47:01 <slaweq> in rfe https://bugs.launchpad.net/neutron/+bug/1847068 proposal is to add dns driver which will ignore designate errors on both port creation and port deletion 14:47:01 <openstack> Launchpad bug 1847068 in neutron "[RFE] create option in neutron.conf to disable designate+neutron consistency" [Wishlist,New] - Assigned to Gregoire Mahe (gregoiremahe) 14:47:24 <slaweq> and it is IMO that driver which is trying to address problem specific to OVH 14:47:53 <slaweq> as they don't want to have e.g. error 500 during port deletion on production if designate will not work properly 14:48:24 <ralonsoh> should be https://review.opendev.org/#/c/685644/ linked to the RFE? 14:49:09 <mlavalle> handling the 500 gracefully seems sensible 14:49:34 <slaweq> ralonsoh: probably it can be 14:49:57 <ralonsoh> ok, 685644 makes sense but not the RFE, got it 14:50:27 <amotoki> I second ralonsoh 14:50:50 <slaweq> mlavalle: yamamoto_: any thoughts about this one? 14:51:19 <mlavalle> as I said already ^^^^, habdling the 500 gracefully seems sensible to me 14:52:15 <mlavalle> inf fact that conversation should be untangled from the RFE 14:52:21 <slaweq> yes, but I'm rather asking about rfe :) 14:52:46 <yamamoto_> does 685644 just log and ignore those errors? 14:52:58 <slaweq> so let's vote about rfe, which is "new designate driver which will not care about what was really created/deleter in designate" 14:53:31 <mlavalle> to me, as I already said, the RFE is specifc to OVH 14:54:02 <slaweq> mlavalle: I agree with You so -1 for this rfe from me 14:55:16 <amotoki> -1 from me too. I am not convinced with the RFE. nova fails to boot a server when neutron fails to create a port for it. I think it is a same situation as what we are discussing. 14:56:04 <mlavalle> exactly 14:56:21 <yamamoto_> does nova fail to delete a server when neutron fails to delete a port? 14:56:25 <mlavalle> the underlying question is how tightly we want to link the services 14:58:04 <mlavalle> well, it sends an instance to error when network resources fail to create, doesn't it? 14:58:09 <slaweq> yamamoto_: I'm not sure but probably not, and nova will left port in neutron in such case 14:58:29 <slaweq> or it set's instance in error state as mlavalle said, I would need to check that 14:58:54 <yamamoto_> what the rfe submitter is unhappy with is "On designate failure, port deletion doesn't work, and the port is not deleted (consistent behavior)" 14:58:54 <amotoki> I cannot remember how nova behaves right now.... but according to the last comment #6 in the RFE what OVH concerns is on port creation 14:58:56 <yamamoto_> right? 14:59:37 <slaweq> yamamoto_: my understanting of this rfe is different 15:00:10 <slaweq> or wait, actually it is correct 15:00:20 <amotoki> he says "consistency" so it looks good for him. 15:00:30 <amotoki> I think the point is on port creation 15:00:42 <ralonsoh> (time is over folks) 15:00:47 <slaweq> but they also want to store any errors somewhere 15:01:02 <yamamoto_> amotoki: but he wants to disable consistency, doesn't he? 15:01:03 <slaweq> ok, we will get back to this one as first one next week 15:01:09 <slaweq> we are out of time today 15:01:16 <slaweq> thx for attending guys 15:01:19 <yamamoto_> i can't attend next week 15:01:20 <ralonsoh> bye 15:01:21 <slaweq> and have a nice weekend 15:01:24 <slaweq> o/ 15:01:26 <yamamoto_> bye 15:01:28 <slaweq> #endmeeting