14:00:19 <slaweq> #startmeeting neutron_drivers
14:00:20 <openstack> Meeting started Fri Oct 11 14:00:19 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:21 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:23 <slaweq> welcome :)
14:00:24 <openstack> The meeting name has been set to 'neutron_drivers'
14:00:27 <yamamoto> hi
14:00:28 <mlavalle> o/
14:00:32 <ileixe_> o/
14:00:48 <njohnston> o/
14:00:54 <haleyb> hi
14:02:35 <slaweq> we have a quorum already so let's start
14:02:47 <slaweq> #topic RFEs
14:02:55 <slaweq> first one for today is:
14:02:58 <slaweq> https://bugs.launchpad.net/neutron/+bug/1759790
14:02:58 <openstack> Launchpad bug 1759790 in neutron "[RFE] metric for the route" [Wishlist,In progress] - Assigned to Bin Lu (369283883-o)
14:04:30 <amotoki> hi
14:08:48 * njohnston refamiliarizes myself with FRR
14:09:05 <slaweq> any thought about this one?
14:09:33 <njohnston> What protocol is the route cost being communicated on?  MPLS, OSPF, BGP, or something else?
14:09:48 <amotoki> is it specific to some third-party L3 backend?
14:11:41 <amotoki> njohnston: I think 'metric' here is metric in linux routing tables for example.
14:11:51 <mlavalle> yes
14:12:14 <slaweq> amotoki: that is also my understanding
14:12:34 <amotoki> metrics are populated by routing protocols like OSPF, BGP and so on, but metric is used by the forwarding plane.
14:13:06 <amotoki> The RFE proposes metric to static routes.
14:13:58 <mlavalle> yesh, in the bug description it shows the body of a request to /routers/router_id
14:14:09 <mlavalle> updating the routes attribute
14:14:24 <mlavalle> adding the metric field
14:14:33 <njohnston> ok, so in ML2/OVS does that become an openflow then?
14:15:39 <amotoki> it sounds reasonable in general. the next question would be about the reference implementation.
14:15:42 <slaweq> njohnston: I believe that in ML2/OVS case with L3 agent it would be set in qrouter- namespace
14:15:50 <mlavalle> amotoki's question is important.... there are comments along the history that seem to imply this won't be implemeneted in "namespace" routers
14:16:37 <mlavalle> I think we should clarify that
14:16:52 <amotoki> mlavalle: agree
14:17:20 <mlavalle> as a pure API addition, seems sensible
14:18:10 <amotoki> Although I haven't checked, linux IP stack supports it, so perhaps it works but it is worth clarifying.
14:18:37 <mlavalle> there is a metric option in the ip command
14:21:00 <mlavalle> seems to be the route command: http://man7.org/linux/man-pages/man8/route.8.html
14:22:18 <amotoki> ip route also supports metric https://www.systutorials.com/docs/linux/man/8-ip-route/
14:22:44 <slaweq> so let's ask in launchpad for clarification of that, if this will be implemented in qrouter namespace, or only as API change which may be consumed by third party L3 drivers
14:22:48 <slaweq> are You ok with that?
14:23:04 <mlavalle> +
14:23:07 <amotoki> +1
14:23:19 <yamamoto> +1
14:23:31 <haleyb> +1
14:23:38 <njohnston> +1
14:23:38 <slaweq> do You want to write this question or should I do this?
14:25:04 <amotoki> slaweq: I can
14:25:10 <slaweq> amotoki: thx
14:25:22 <amotoki> I will add it after the meeting
14:25:54 <slaweq> so I think we can move on to the next one than
14:26:01 <slaweq> https://bugs.launchpad.net/neutron/+bug/1845622
14:26:01 <openstack> Launchpad bug 1845622 in neutron "[RFE] Decouple allow_address_pair service with security_group" [Undecided,Confirmed]
14:29:56 <njohnston> the use case makes sense to me
14:30:00 <amotoki> I haven't fully understood the motivation of this request.... I am not sure what is the expected use cases of allowed_address_pairs by this proposal.
14:30:53 <amotoki> originally allowed_address_pairs extension was introduced to allow a neutron port to have more IPs/subnets along with security groups.
14:31:15 <mlavalle> I think I saw the submitter join the meeting, ileixe_
14:31:16 <amotoki> so I wonder what does the standalone allowed-address-pairs mean.
14:31:21 <slaweq> amotoki: I think their use case is described in https://bugs.launchpad.net/neutron/+bug/1845622/comments/
14:31:21 <openstack> Launchpad bug 1845622 in neutron "[RFE] Decouple allow_address_pair service with security_group" [Wishlist,Confirmed]
14:31:25 <slaweq> sorry: https://bugs.launchpad.net/neutron/+bug/1845622/comments/2
14:31:44 <slaweq> ileixe_: hi
14:32:04 <slaweq> ileixe_: do You want to elaborate on use case behind this rfe?
14:32:08 <njohnston> basically it sounds like they cannot use octavia when enable_security_group=False because that setting disables allowed_address_pair, right?
14:32:16 <ileixe_> Yes
14:32:31 * mlavalle left comments in another of his submissions last night, so got familiar with the nickname
14:32:50 <ileixe_> Ys to njohnston
14:32:51 <ileixe_> hi guys
14:33:06 <mlavalle> well, no in other comment ileixe_ seems to idndicate they have a workaround
14:33:14 <mlavalle> with the noop driver
14:33:26 <ileixe_> Yes, we had been used like that
14:33:39 <mlavalle> so why change it
14:33:40 <mlavalle> ?
14:34:52 <ileixe_> Hm.. there were several reasons related to our codes
14:34:58 <ileixe_> but my point is
14:35:02 <amotoki> ileixe_: what is the root cause that octavia cannot work when enable_security_group=False? Is it just because octavia assumes allowed_address_pairs exist?
14:35:20 <ileixe_> Yes for octavia
14:35:48 <ileixe_> But I did not assume that allowed_address_pairs directly related to security group
14:35:53 <ileixe_> sorry for my slow response
14:35:55 <ileixe_> T_ T
14:36:02 <amotoki> ileixe_: no worries
14:36:03 <ileixe_> but if then
14:36:07 <ileixe_> it can be invalid
14:36:19 <ileixe_> I don't know the extension cames from
14:36:33 <johnsom> Our amphora driver requires AAP to manage the VIP address. Basically having a second IP on a port.
14:36:34 <ileixe_> In fact, we've been used the extension for other purpose
14:37:02 <mlavalle> johnsom: so it is actually used, right?
14:37:48 <johnsom> Yes, AAP is always used with the amphora driver. It is not optional.
14:38:41 <slaweq> johnsom: so if You would e.g. disable port security on such amphora port, octavia would fail to work?
14:38:46 <amotoki> johnsom: what is AAP?
14:38:49 <mlavalle> but if you were to configure the noop firewall, you get AAP and problem is fixed, right?
14:39:01 <mlavalle> AAP == Allowed Address Pairs
14:39:29 <johnsom> Allowed Address Pairs (AAP) (on mobile)
14:39:31 <amotoki> ah...
14:40:17 <johnsom> mlavalle: I do not know on the firewall noop.
14:40:24 <ileixe_> mlavalle: Yes we've been used like that
14:40:44 <mlavalle> so again, why fix it if it ain't broke?
14:41:18 <ileixe_> hm.. I think it's right direction and it do break other our custom code..
14:41:48 <amotoki> ileixe_: from the historical background, allowed-address-pairs ext was introduced to allow a neutron port to have more IP addresses, so the AAP extension is an enhancement of security group API.
14:42:08 <amotoki> ileixe_: if you use allowed-address-pairs for different purposes, it is another topic.
14:42:36 <ileixe_> Yes, if it couples security group a lot, again I think the request is invald
14:42:52 <mlavalle> and in principle, tailor the reference implementation to your custom code is not a very strong reason to change the reference implementation
14:43:19 <ileixe_> Ok i understand
14:43:36 <mlavalle> unless we can show we are going to benefit many other deployers, so we justify the effort and risk of changing the reference implemenatation code
14:43:53 <yamamoto> i guess you should explain what your "custom code" does
14:44:20 <slaweq> I agree with mlavalle
14:44:20 <ileixe_> What I think about AAP is
14:44:22 <mlavalle> ileixe_: I am not saying no.... I am saying we need to understand a deep reason to do this
14:44:38 <ileixe_> to provide additional IP for the port
14:44:45 <mlavalle> because this code belongs to a community
14:44:47 <ileixe_> to enabble ACL
14:45:14 <ileixe_> so what we have done for the port is to add some routing for the port when AAP is added
14:45:28 <johnsom> I cannot seem to open the bug on my phone, so I have no context here
14:45:29 <ileixe_> But.. I think it's not very common
14:46:10 <njohnston> ileixe_: Why is it that you want to shift from firewall_driver=noop to enable_security_groups=false?
14:46:26 <ileixe_> That's also because...
14:46:32 <njohnston> ileixe_: Is there a driver for that use case that could be applied to other openstack clouds?
14:46:36 <ileixe_> we have to add some logics when seucirty group enabled
14:46:43 <ileixe_> I don't want to
14:46:45 <mlavalle> ileixe_: I think we can explore this further, if you are willing to explain your use case further. So far, you have proposed a "what to do" (detach AAP from sec groups) but maybe the why (your use case) can be benefitial to the community
14:47:04 <ileixe_> hm..
14:47:20 <ileixe_> I think it's better to explain our architecture first
14:47:25 <ileixe_> And its anothoer RFE
14:47:36 <ileixe_> can we deal with them first...?
14:47:41 <yamamoto> ileixe_: by somehow watching the updates of aap values?
14:47:47 <ileixe_> Yes
14:49:23 <slaweq> maybe we can ask community if such use case would be useful for others also? E.g. on openstack-discuss ML?
14:49:33 <ileixe_> We don't use security group, but when security group enabled, we have to add some logic for that (to bypass arp snooping rule). So I just want to use without security group.
14:49:59 <amotoki> I think ileixe_'s interpretation of allowed-address-pairs is correct. allowed-address-pairs attribute defines what IPs and ranges are behind the port.
14:50:35 <amotoki> it was introduced to enhance the security group, but the understanding looks valid.
14:51:56 <njohnston> ileixe_: so the real problem you're trying to overcome is the mac snooping protection?
14:52:56 <ileixe_> Yes that was root cause
14:53:13 <amotoki> ileixe_: if so, port_security=False doesn't work for you?
14:53:15 <slaweq> IIUC there are already at least 2 valid use cases of using AAP without security groups: ileixe_'s one and Octavia's one, right?
14:53:36 <mlavalle> it's the same, isn't it?
14:53:50 <mlavalle> ileixe_ wants this to use Octavia, right?
14:53:57 <ileixe_> Yes
14:54:01 <slaweq> ahh, ok
14:54:08 <slaweq> so my understanding wasn't correct
14:54:11 <slaweq> sorry
14:54:14 <mlavalle> but he has a way to do it now, right?
14:54:26 <mlavalle> namely, the noop firewall
14:54:42 <ileixe_> Yes it's not a problme for whom use reference implemtations
14:55:20 <johnsom> Yeah, to my knowledge the Octavia team is not asking for this change. What we have today works for us in general.
14:55:54 <ileixe_> amotoki: I think it's not directly related to my issue but I will take a look at it. Thanks.
14:56:57 <mlavalle> and I understand that conceptually, it might be cleaner if AAP wasn't coupled to security groups.... but at this point it only seems conceptual... we don't have a specifc use case to enable at this point
14:57:22 <mlavalle> I mean a broken use case that we need to enable
14:57:25 <liuyulong> Maybe you should separate an isolated AZ for Octavia amphora to run instance without security group (firewall). And run users' normal instances to those hosts which enable the security group?
14:57:25 <slaweq> ok, so should we postpone this rfe until there will be more valid use cases for that?
14:57:38 <amotoki> we have 5mins left. my suggestion on the next step is that ileixe_ clarify what is the real needs.
14:57:43 <ileixe_> Yes
14:57:46 <ileixe_> agreed
14:58:00 <slaweq> amotoki: ok
14:58:04 <slaweq> sounds good
14:58:10 <yamamoto> +1
14:58:14 <ileixe_> liuyulong: Thanks I gonna look at it also
14:58:46 <njohnston> agreed.  In particular ileixe_'s statement "when security group enabled, we have to add some logic for that (to bypass arp snooping rule)" is something that I don't see happening with the noop firewall driver, looking at the code.  I don't see arp spoofing protection happening with noop.
14:59:13 <mlavalle> thanks ileixe_. we really appreciate your submission. whatever pushback I gave here is in the interest of identifying use cases valid from a community perspective
14:59:42 <slaweq> ok, thx for attending, we are on top of the hour now
14:59:45 <ileixe_> my presure
14:59:46 <ileixe_> :)
14:59:54 <slaweq> have a great weekend everyone :)
14:59:57 <slaweq> o/
15:00:07 <slaweq> #endmeeting