14:00:12 <slaweq> #startmeeting neutron_drivers
14:00:13 <openstack> Meeting started Fri Oct 25 14:00:12 2019 UTC and is due to finish in 60 minutes.  The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:15 <slaweq> hi
14:00:17 <openstack> The meeting name has been set to 'neutron_drivers'
14:00:21 <mlavalle> o/
14:00:41 <haleyb> hi
14:00:49 <ralonsoh> hi
14:01:15 <amotoki> o/
14:01:24 <slaweq> yamamoto sent an email today that he will not be able to join, so I think we can start now
14:01:41 <slaweq> #topic RFEs
14:01:58 <slaweq> first rfe for today is:
14:02:01 <slaweq> https://bugs.launchpad.net/neutron/+bug/1825345
14:02:01 <openstack> Launchpad bug 1825345 in neutron "[RFE] admin-state-down doesn't evacuate bindings in the dhcp_agent_id column" [Wishlist,Confirmed]
14:02:05 <slaweq> we discussed about it last week
14:02:18 <slaweq> zigo made some clarifications about it in the comment
14:02:55 <zigo> o/
14:03:09 <slaweq> and personally I think that this rfe makes sense and it makes sense to do it on server side as was proposed by zigo
14:03:12 <slaweq> hi zigo :)
14:04:33 <zigo> Does it make sense to also broaden the scope, and have it for l3-agent?
14:05:01 <zigo> There too, someone may want to move routers away.
14:05:01 <amotoki> it sounds reasonable to me too.
14:05:06 <slaweq> zigo: IMO yes, it should works in same way for dhcp and l3 agents
14:05:40 <amotoki> when I was an operator, I wrote a similar script to evacuate networks/routers and it is same as what this RFE proposes.
14:07:54 <mlavalle> sounds reasonable to me as well
14:08:07 <slaweq> haleyb: what's Your opinion about it?
14:08:32 <haleyb> slaweq: i'm +1 for it
14:09:01 <slaweq> thx
14:09:09 <slaweq> so I will approve this rfe
14:09:37 <slaweq> zigo: if You want/need help with implementing that I would be happy to help :)
14:12:18 <slaweq> approved, lets move to the next one
14:12:22 <slaweq> https://bugs.launchpad.net/neutron/+bug/1840979
14:12:22 <openstack> Launchpad bug 1840979 in neutron "[L2] update the port DB status directly in agent-side" [Wishlist,In progress] - Assigned to LIU Yulong (dragon889)
14:14:03 <ralonsoh> updating the DB in the agent?
14:14:13 <ralonsoh> is that correct?
14:14:32 <slaweq> ralonsoh: yes, that's the proposal in this rfe basically
14:14:54 <slaweq> so each ovs agent would have access to db directly to improve performance
14:15:14 <ralonsoh> this is something I don't support, regardless of the idea of having a distributed system
14:15:30 <ralonsoh> but because Neutron server was not designed in this way, we should not support it
14:16:17 <amotoki> it can improve performance but it makes the upgrade difficult. when DB schema change happens, neutron agents cannot talk with DB until neutron agents are upgraded.
14:16:43 <ralonsoh> and this is another reason
14:16:57 <slaweq> amotoki: yes, upgrade is one of the reasons why I'm also against this
14:17:13 <slaweq> another is less security IMO
14:17:50 <slaweq> liuyulong said in one of the comments there that e.g. cinder and nova are doing something like that
14:17:54 <mlavalle> and if we have a plan to converge with OVN, why would we want to take such a radical step with agents?
14:18:35 <mlavalle> let's focus on the OVN convergence
14:19:26 <haleyb> +1, i don't think agents having direct access is a good idea either
14:20:47 <slaweq> ok, I think that we all agree here that it's not good idea to make such radical change in neutron's architecture
14:21:38 <slaweq> so I will summarize all those reasons in comment to the rfe and will close it as not approved - is it ok for You?
14:21:59 <mlavalle> yes
14:22:03 <amotoki> works forr me
14:22:16 <ralonsoh> ok
14:22:38 <haleyb> ok for me
14:23:07 <slaweq> ok, thx
14:23:12 <slaweq> we are going very fast today
14:26:57 <slaweq> ok, done
14:28:12 <slaweq> next one on my list is https://bugs.launchpad.net/neutron/+bug/1847068
14:28:12 <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:28:18 <slaweq> but I'm not sure if gregoiremahe is here tody
14:28:21 <slaweq> *today
14:30:06 <slaweq> personally I don't think that such "inconsistent" designate driver should be in neutron repo as it fits very specific usecase of OVH
14:30:19 <mlavalle> so his challenge is that the Designate is not available all the time, right?
14:30:53 <mlavalle> *the Designate API
14:31:25 <slaweq> mlavalle: TBH I'm not sure, I think they have custome driver in designate for OVH dns service and maybe this isn't available always
14:31:44 <slaweq> but we would need to have gregoiremahe here to explain that in details
14:32:31 <mlavalle> current DNS integration was designed under the assumption that the Designate API is most of the time available
14:32:41 <mlavalle> and I think that is a reasonable assumption to make
14:33:15 <mlavalle> and that is proven by the fact that other operators use it succesfully
14:33:35 <mlavalle> my employer among them
14:34:04 <mlavalle> so yes, I think this RFE is a very OVH specific request
14:34:19 <slaweq> so here is what I propose for now:
14:35:34 <slaweq> I will ask gregoiremahe to explain in more details what he meant in his last comment in this BZ and to provide maybe details about his usecase for that
14:36:02 <slaweq> than we can maybe check once again if that makes sense to have new driver in neutron tree or not
14:36:10 <slaweq> is it fine for You?
14:36:43 <mlavalle> IMO, we can evaluate any option as long as what exists today is not touched
14:37:31 <slaweq> mlavalle: that's for sure, I don't think that touching existing designate driver would be needed for that
14:37:51 <slaweq> IMO it's clear that we are considering only new driver potentially
14:40:15 <amotoki> slaweq: your plan sounds good to me.
14:40:38 <slaweq> thx amotoki and mlavalle for Your opinions about this one
14:41:27 <amotoki> side note: Step #2 in the bug description sounds similar to a journalling mechanism proposed to sync netwokring-ovn/odl with neutron server.
14:44:23 <slaweq> amotoki: right, it sounds similar to that mechanism
14:45:21 <slaweq> ok, lets move on than
14:45:26 <slaweq> next one on the list is
14:45:29 <slaweq> https://bugs.launchpad.net/neutron/+bug/1846285
14:45:29 <openstack> Launchpad bug 1846285 in neutron "[RFE] routed network for hypervisor" [Undecided,Confirmed]
14:45:56 <slaweq> mlavalle was asking some questions there, and reporter of the rfe answers them
14:46:21 <slaweq> but I'm not sure if that's enough for mlavalle to make this rfe clear
14:46:43 <slaweq> personally I'm not routed networks expert so it's hard for me to triage that rfe
14:46:59 <slaweq> so I wanted to check others opinions about it
14:47:37 <mlavalle> well, look at his number 1 answer
14:48:20 <mlavalle> essentially he is saying that he is going to change the way things work now
14:48:47 <mlavalle> in other words, if we move in that direction, everybody needs to move in that direction
14:49:00 <mlavalle> I mean all the deployers
14:49:38 <mlavalle> now, I am not saying this is not an interesting idea
14:50:13 <mlavalle> because it is
14:50:56 <mlavalle> but the price cannot be be that everybody needs to adopt this way to deploy Neutron
14:51:19 <slaweq> mlavalle: segments are done as separate service plugin, right?
14:51:29 <mlavalle> yes
14:51:37 <slaweq> mlavalle: can't this be proposed as another service plugin maybe? even outside of the neutron tree
14:52:06 <mlavalle> let's clarify something
14:52:20 <mlavalle> segments plugin != routed networks
14:52:42 <mlavalle> segments plugin is used in routed networks
14:52:52 <mlavalle> but routed networks is more that that
14:53:18 <mlavalle> routed networks use segments
14:53:51 <mlavalle> the segments plugin was a way to make a concept that already existed (segments) directly accesible from the API
14:54:44 <mlavalle> it was a way to make segments a resource in the API. But segments existed in ML2 way before that
14:55:15 <mlavalle> having said that, yes, this could be implemented as a different plugin
14:55:30 <slaweq> so this rfe would require changes in ml2 plugin also?
14:56:00 <mlavalle> submitter hasn't given dteailed information
14:56:20 <mlavalle> but his comments suggest changes in L3 and L2 at least
14:56:32 <mlavalle> again, the idea is interesting
14:56:38 <slaweq> mlavalle: can You take care of this rfe and continue triaging it?
14:56:54 <mlavalle> and I would be happy to experiment with the idea
14:57:20 <mlavalle> but I don't want to commit Neutron to something that would force everybody to deploy in this way
14:58:15 <mlavalle> slaweq: yes, that was my plan and then you marked it as triaged
14:58:25 <slaweq> mlavalle: sorry for that
14:58:39 <mlavalle> slaweq: no problem whatsoever
14:58:46 <mlavalle> I am complaining
14:59:00 <mlavalle> I am just sharing my thoughts and how I see this has evolved
14:59:06 <slaweq> I will now change it back to "rfe" and we will wait for when You will think it's triaged :)
14:59:27 <mlavalle> I am not complaining
14:59:38 <mlavalle> that;s what I meant to say slaweq^^^
14:59:47 <slaweq> thx a lot for update about this mlavalle
14:59:53 <slaweq> we are almost out of time now
14:59:58 <slaweq> thx for attending the meeting
15:00:03 <ralonsoh> bye
15:00:08 <ileixe___> Thanks :)
15:00:08 <slaweq> and have a great weekend guys
15:00:12 <amotoki> thanks
15:00:16 <slaweq> o/
15:00:17 <mlavalle> slaweq: nest week I won't attend. I'll be on my way to China
15:00:19 <slaweq> #endmeeting