14:00:23 <lajoskatona> #startmeeting neutron_drivers
14:00:23 <opendevmeet> Meeting started Fri Jul 22 14:00:23 2022 UTC and is due to finish in 60 minutes.  The chair is lajoskatona. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:23 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:23 <opendevmeet> The meeting name has been set to 'neutron_drivers'
14:00:24 <mlavalle> o/
14:00:27 <lajoskatona> Hi
14:00:31 <obondarev> hi
14:00:34 <ralonsoh> hello
14:00:36 <lajoskatona> Let's see if we have enough drivers
14:00:39 <yamamoto> hi
14:02:10 <spatel> ralonsoh I am running frr 7.2.1 and ovn-bgp-agent checkout from latest clone, openstack is latest master from devstack openvswitch-switch  version 2.13.5
14:02:31 <lajoskatona> ok, let's start
14:02:31 <ralonsoh> spatel, let's talk after the meeting
14:02:37 <spatel> sure!
14:02:42 <lajoskatona> ralonsoh, spatel: thanks
14:02:52 <lajoskatona> We have one RFE for today:
14:02:56 <amotoki> hi
14:02:59 <lajoskatona> [rfe][ovn] Support address group for ovn driver (#link [rfe][ovn] Support address group for ovn driver )
14:03:35 <lajoskatona> sorry wrong link: https://bugs.launchpad.net/neutron/+bug/1982287
14:04:46 <mlavalle> how is this different to address groups?
14:04:50 <lajoskatona> If I understand well the OVN side of this feature is already there, just the ml2_ovn part is missing
14:05:04 <mlavalle> or is it the same concept just directly supported by ovn
14:05:07 <mlavalle> ?
14:05:18 <lajoskatona> mlavalle: yes as I see the same feature but with OVN
14:05:20 <ralonsoh> it is the same, just missing the implementation in OVN
14:05:46 <amotoki> ralonsoh: more precisely, missing in ML2/OVN?
14:06:04 <ralonsoh> exactly, core OVN supports that
14:06:08 <obondarev> seems pretty obvious to approve then :)
14:06:13 <mlavalle> yeap
14:06:18 <lajoskatona> obondarev: +1
14:06:24 <mlavalle> brings parity to ml2 / ovn
14:06:57 <mlavalle> to me, it is a no brainer
14:07:06 <obondarev> only question from me if it's needs a spec or not
14:07:56 <mlavalle> yeah, let's ask a spec, specifically explaining how this play with the current address groups implementation
14:08:03 <amotoki> I don't think so. a spec is not necessarily required and this looks straight-forward
14:08:08 <obondarev> if the API/interface is same that neutron already has - then probably no spec is needed
14:08:18 <ralonsoh> I don't think there will be any API/DB change
14:08:21 <mlavalle> yeap, that was my concern
14:08:37 <ralonsoh> so spec maybe won't be necessary
14:08:44 <mlavalle> it is is going to stick to the current API and DB, the no spec is needed
14:08:57 <mlavalle> if it ^^^
14:09:03 <lajoskatona> agree, if it is just to adopt ovn driver to create address sets based on the API req of address groups, I see no need for spec
14:09:21 <mlavalle> but let's indicate that when we approve the RFE
14:09:27 <mlavalle> explicitely
14:09:35 <mlavalle> so expectations are clear
14:09:36 <amotoki> +1
14:10:01 <obondarev> +1
14:10:04 <ralonsoh> +1
14:10:07 <lajoskatona> Ok, so I add comment to the RFE that if the same API and db can be used the RFE can go without spec, otherwise let's request one
14:10:08 <yamamoto> +1
14:10:12 <haleyb> +1
14:10:31 <obondarev> if only all RFEs be so nice!
14:10:36 <lajoskatona> ok, it was quick :-)
14:10:37 <ralonsoh> hehehe
14:10:39 <atimmins> Could we also please have an update on https://bugs.launchpad.net/neutron/+bug/1979816 before we close today?
14:11:47 <ralonsoh> atimmins, let's finish the previous topic
14:12:43 <lajoskatona> I think we accepted the RFE with the condition that it is "only" an OVN driver
14:12:51 <ralonsoh> perfect
14:12:55 <lajoskatona> #topic On Demand Agenda
14:13:28 <lajoskatona> atimmins: you refer to your last comment on the RFE pointing to the etherpad: https://etherpad.opendev.org/p/fwaas-api-evolution-spec#L244 ?
14:13:38 <atimmins> Yes
14:15:48 <lajoskatona> atimmins: if this strata concept covers your issue with fw goup ordering, isn't that good to create a spec based on this in the etherpad?
14:16:00 <luis5tb> spatel, sorry I missed this... note the blogpost is a bit old, and there has been quite some changes
14:16:30 <luis5tb> spatel, there is a WIP patch for devstack support https://review.opendev.org/c/x/ovn-bgp-agent/+/814185
14:16:44 <luis5tb> perhaps yo ucan take some ideas about how you shoul configure theee agent for devstack
14:16:57 <spatel> luis5tb working with ralonsoh and made some progress but stuck here https://paste.opendev.org/show/bYxy4cBWygOQ21JgEJZb/
14:17:05 <atimmins> Perhaps I am just unaware of the process for creating a spec - is that something I should do myself, and if so, is there documented guidance for doing so?
14:17:57 <mlavalle> atimmins: this is the neutron specs repo: https://opendev.org/openstack/neutron-specs
14:18:08 <ralonsoh> atimmins, you need to propose something like this
14:18:09 <ralonsoh> https://github.com/openstack/neutron-specs/blob/master/specs/yoga/distributed-metadata-data-path.rst
14:18:17 <lajoskatona> exactly
14:18:30 <ralonsoh> in any case, what is in the etherpad is different from group ordering
14:18:37 <mlavalle> atimmins: please note there is a directory for the zed cycle: https://opendev.org/openstack/neutron-specs/src/branch/master/specs/zed
14:18:51 <ralonsoh> you are introducing priority levels (but we can discuss this in the spec)
14:19:09 <mlavalle> yes, the spec would be a good place to discuss that
14:19:13 <ralonsoh> and, btw, in the previous meeting we talked about the current behaviour
14:19:27 <ralonsoh> that doesn't match the current spec (allow by default)
14:20:00 <mlavalle> atimmins: please also note that in that zed directory there is a placeholder.rst file that you can use as a template
14:20:39 <atimmins> This is all very helpful, thanks! I'll work on putting a spec together in the zed directory.
14:20:44 <mlavalle> when you have you first version of the spec, just submmit is to gerrit with git review, like any other patch in the OpenStack project
14:21:19 <atimmins> Will do
14:21:22 <mlavalle> atimmins: and we will have a discussion over gerrit, just like any other piece of code
14:21:23 <lajoskatona> atimmins: before pushing you can build it with tox -edocs I think, and can check in browser
14:22:19 <lajoskatona> I have another quick sentence for today:
14:22:33 <lajoskatona> I started the Antelope etherpad: https://etherpad.opendev.org/p/neutron-antelope-ptg
14:22:40 <mlavalle> cool!
14:22:56 <lajoskatona> and the next release will be Antelope :-)
14:23:09 <mlavalle> so bad for anteater
14:23:30 <lajoskatona> I think antelope is much better for marketing people :-)
14:24:08 <lajoskatona> If there is no more topics to discuss, let's close the meeting
14:24:11 <haleyb> the anteater would have gotten all the bugz :)
14:24:30 <lajoskatona> haleyb: that was my reasoning also :-)
14:25:10 <haleyb> but there are no bugs left, coffee must be working if i'm talking
14:25:32 <lajoskatona> :-)
14:25:41 <lajoskatona> #endmeeting