14:01:05 <slaweq> #startmeeting neutron_drivers
14:01:06 <openstack> Meeting started Fri Jan 29 14:01:05 2021 UTC and is due to finish in 60 minutes.  The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:07 <slaweq> hi
14:01:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:10 <openstack> The meeting name has been set to 'neutron_drivers'
14:01:14 <mlavalle> o/
14:01:21 <yamamoto> hi
14:01:39 <amotoki> hi
14:01:39 <ralonsoh> hi
14:02:34 <bpetermann> hi
14:02:47 <slaweq> lets wait few more minutes for haleyb and njohnston
14:02:54 <haleyb> hi
14:03:15 <njohnston> o/
14:03:39 <slaweq> ok, all are here
14:03:42 <slaweq> so we can start
14:03:46 <slaweq> #topic RFEs
14:03:56 <slaweq> https://bugs.launchpad.net/neutron/+bug/1912460
14:03:57 <openstack> Launchpad bug 1912460 in neutron "[RFE] [QoS] add qos rule type packet per second (pps)" [Wishlist,New]
14:05:07 <slaweq> ralonsoh: You were triaging this LP mostly :)
14:05:07 <ralonsoh> I don't think Liu is here
14:05:17 <ralonsoh> ok, in a nutshell
14:05:49 <ralonsoh> I agree with the idea of this new rule because can be supported directly by some backends
14:06:08 <ralonsoh> and about if adding this as a new parameter in the BW limit rule or create a new one
14:06:30 <ralonsoh> I prefer to add a new one and discriminate by backend, as the other ones
14:06:43 <ralonsoh> so +1 from me to this RFE
14:07:54 <slaweq> personally I think it may be very useful in some use cases to have such new QoS rule type
14:08:01 <slaweq> and I agree that this can be new rule type
14:08:11 <amotoki> I prefer to add a new rule rather tahn a new param in the bw rule as bw usually assocaite bps in the networking world.
14:08:28 <ralonsoh> agree
14:09:51 <slaweq> yep, and also adding too many parameters to same rule type would made it "overloaded" IMO
14:10:28 <amotoki> slaweq: +1
14:12:05 <yamamoto> +1 for a new rule type
14:12:34 <mlavalle> I agree with Yulong that we shouldn't mix pps with bandwidth with that approach, +1 from me
14:12:58 <haleyb> +1 for new rule
14:13:24 <slaweq> njohnston: are You ok with this too?
14:13:32 <slaweq> if so, I will mark it as approved
14:13:56 <njohnston> yes I am, ralonsoh is very persuasive :-)
14:14:04 <slaweq> :)
14:14:08 <slaweq> ok, so rfe approved
14:14:10 <slaweq> thx
14:14:14 <slaweq> that was the only one for today
14:14:20 <slaweq> but I have another topics
14:14:27 <slaweq> #topic On demand
14:14:37 <slaweq> first one from bpetermann
14:14:39 <slaweq> https://bugs.launchpad.net/neutron/+bug/1905391
14:14:42 <openstack> Launchpad bug 1905391 in neutron "[RFE] VPNaaS support for OVN" [Medium,Triaged] - Assigned to Bodo Petermann (bpetermann)
14:15:17 <bpetermann> Thanks. We had this RFE in December. I wanted to ask if the spec is generally fine
14:15:36 <bpetermann> or if there is anything major that needs to be changed
14:16:20 <amotoki> I failed to find time to review the latest spec, but when I commented in the spec review it was generally good and I see no blocking issue.
14:17:22 <bpetermann> slaweq, you asked about rabbitmq. rabbit was used by the existing VPNaaS implementation to sync the config. Is it ok to keep using rabbit?
14:18:25 <slaweq> bpetermann: I know it was but my concern is that one of the biggest advantages of using ovn is that we don't need rabbitmq anymore
14:18:38 <slaweq> I'm not against if there is no other (simple) way
14:18:46 <slaweq> just wanted to raise this concern there
14:19:10 <amotoki> i think it is okay to use rabbitmq as the proposed agent is implemented in the neutron side rather than the ovs/ovn side. of course it would be nice if we can support it without rabbitmq.
14:19:37 <bpetermann> ok, because for now I don't know a good way to get the config across without rabbit
14:20:30 <amotoki> any discssion on VPN support in the OVN side? > OVN folks
14:20:54 <slaweq> bpetermann: maybe You can talk with jlibosva or lucasgomes as they are our ovn experts
14:20:57 <slaweq> or ralonsoh :)
14:21:10 <ralonsoh> (I didn't review the spec or the patch)
14:21:27 <slaweq> as currently we have ovn-metadata agent and it works somehow and e.g. sends heartbeats to the server
14:21:28 <yamamoto> midonet vpn is implemented without rabbitmq. i dunno if you consider it "simple" though.
14:22:01 <mlavalle> don't we habe LB for OVN?
14:22:24 <bpetermann> midonet uses zookeeper for the configuration, right?
14:22:30 <yamamoto> bpetermann: yes
14:22:38 <slaweq> mlavalle: we have ovn-octiavia provider
14:22:54 <slaweq> bpetermann: so my suggestion is to explore other alternatives at least
14:23:09 <slaweq> and maybe mention them in spec as potential solutions, or maybe next steps
14:23:12 <slaweq> wdyt?
14:23:17 <haleyb> mlavalle: we have a provider driver for octavia, but it lives in their framework
14:23:53 <mlavalle> slaweq, bpetermann, haleyb: but still, they solve this problem somehow, right?
14:24:13 <mlavalle> maybe we should take a look at how they do it
14:25:15 <mlavalle> and yes, let's avoid using rabbitmq if we can. It defeats the purpose of the whole OVN adoption
14:26:05 <haleyb> right, there's no rabbit in octavia
14:26:19 <bpetermann> the agent could look into the neutron database instead of using RPCs to get the necessary parameters. For other ways I'd need to do more research
14:26:47 <mlavalle> let's do some research, I'd say
14:26:48 <slaweq> bpetermann: no, please don't make agent with access to db directly
14:26:55 <bpetermann> ok
14:26:57 <slaweq> I don't think it's good idea
14:27:05 <mlavalle> yes, don't have the agent look at the db directly
14:28:54 <bpetermann> I will then look into alternatives to rabbit in the next days
14:29:04 <amotoki> I agree we need more research without rabbitmq but it depends on how OVN itself support VPN. If we need more work in the neutron layer the current approach sounds good to me.
14:29:16 <amotoki> this is my current impression so far.
14:29:20 <slaweq> amotoki++
14:31:34 <slaweq> bpetermann: is that enough info for You for now? or do You want to discuss something else?
14:32:16 <bpetermann> that's all. I think the question on using rabbit or not was the most important one.
14:32:42 <slaweq> ok
14:32:56 <slaweq> so please update spec and we can continue review of it
14:33:03 <bpetermann> will do
14:33:10 <slaweq> thx bpetermann
14:33:18 <slaweq> so, one last topic for today
14:33:22 <mlavalle> thanks bpetermann
14:33:23 <slaweq> this one from me
14:33:39 <slaweq> some time ago gmann sent email about tag 'assert:supports-api-interoperability'
14:33:44 <slaweq> http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019505.html
14:33:55 <slaweq> I was reading related docs recently
14:34:05 <slaweq> and for me it sounds like Neutron can apply for such tag
14:34:13 <slaweq> I wanted to ask You wdyt about it
14:34:24 <slaweq> is it ok, is it worth to do or not in Your opinion?
14:34:25 <ralonsoh> I think we follow the 3 requirements
14:35:33 <njohnston> Given that we have some users using Train Octavia on Queens Neutron I think we have a very good case that we deserve this tag
14:37:20 <mlavalle> yeah, let's go for it. It doesn't buy us anything.... but it is certainly valuable information and an important commitment to our users
14:37:39 <cgoncalves> wasn't there an API breakage in Neutron to fix some IPV6 issue?
14:38:02 <amotoki> I generally think we can go for it. I wonder what are the requirements for projects without microversions (like keystoen and neutron).
14:38:10 <ralonsoh> cgoncalves, you mean in the DHCP agent?
14:38:26 <cgoncalves> ralonsoh, I'm not sure of the details. I think haleyb knows best as he authored that patch...?
14:38:32 <mlavalle> amotoki: "The projects API uses a versioning scheme (like microversions) or a discoverablity mechanism"
14:38:37 <haleyb> i think it had to do with icmpv6
14:39:03 <haleyb> under the covers we change the name, so what goes in comes out different
14:39:18 <haleyb> if my memory serves me right
14:39:18 <amotoki> mlavalle: thanks. good point. we provide a good discoverability mechanism :)
14:39:26 <slaweq> amotoki: I think that our extensions are discoverability mechanism already
14:40:00 <slaweq> haleyb: cgoncalves but was this change breaking exiting users in any way?
14:41:26 <haleyb> i'm thinking octavia noticed :D
14:41:31 <cgoncalves> slaweq, does it matter if someone hit such breakage?
14:42:44 <slaweq> cgoncalves: my question was more about "was this really breaking change"? IIRC we are still accepting old values, but I may be wrong so please correct me
14:42:48 <haleyb> well, we make mistakes and won't do it again, don't think that we should ask for this tag for that, the API in question still accepts all the old values on POST/PUT
14:42:58 <amotoki> we cannot be perfect but I believe we honor the API compatibility and we are doing our best to follow it, so I think we can go for it.
14:43:02 <haleyb> s/ask/not ask
14:43:53 <mlavalle> yes, go for it
14:44:52 <slaweq> ok, thx for You opinions, I will apply for this tag for Neutron then
14:45:06 <slaweq> that's all what I had for today
14:45:14 <slaweq> do You want to discuss anything else?
14:45:20 <slaweq> if not I will give You 15 minutes back
14:45:20 <mlavalle> not me
14:45:30 <ralonsoh> no thanks
14:45:31 <amotoki> none from me
14:45:35 <yamamoto> nothing
14:45:37 <haleyb> -1
14:46:09 <slaweq> ok, so thx for attending the meeting and have a great weekend
14:46:13 <slaweq> #endmeeting