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