14:00:57 <ralonsoh> #startmeeting neutron_drivers
14:00:57 <opendevmeet> Meeting started Fri May 19 14:00:57 2023 UTC and is due to finish in 60 minutes.  The chair is ralonsoh. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:57 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:57 <opendevmeet> The meeting name has been set to 'neutron_drivers'
14:00:59 <ralonsoh> hello all
14:01:01 <amotoki> hi
14:01:09 <slaweq> o/
14:01:12 <haleyb> o/
14:01:29 <ralonsoh> Lajos is not attending today
14:01:34 <ykarel> o/
14:01:52 <mtomaska> o/
14:02:07 <ralonsoh> ok, I think we have quorum
14:02:12 <ralonsoh> let's start with the first topic
14:02:20 <ralonsoh> from liushy
14:02:27 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/2016504
14:02:32 <ralonsoh> [rfe]Support specify fixed_ip_address for DHCP or Metadata port
14:02:36 <ralonsoh> liushy, please
14:02:45 <liushy> Hi all
14:02:52 <sahid> o/
14:03:53 <liushy> We want define a new api that can specify the fixed_ip for dhcp port or metadata port
14:04:51 <liushy> In this time, we firstly need agree the new api extention
14:04:52 <slaweq> did You try to create manually port with fixed_ip which You want and with device_owner set as "reserved_dhcp_port"? IMO such port should be later used by dhcp agent as dhcp port when network will be scheduled to the dhcp agent
14:06:27 <sahid> slaweq: whao interesting :-)
14:07:10 <liushy> Yeah, it is, but I have no good idea for reserved_dhcp_port
14:07:39 <ralonsoh> what do you mean? sorry, I don't understand
14:07:41 <liushy> Maybe this reserved dhcp port would not been
14:07:46 <liushy> Used
14:09:08 <ralonsoh> by who? this is the same as any other DHCP port. In any case, this is an alternative to be explored
14:09:17 <ihrachys_> (it's device_id, not device_owner0
14:09:38 <ralonsoh> yes, device_id
14:09:39 <ralonsoh> if port_device_id == constants.DEVICE_ID_RESERVED_DHCP_PORT
14:09:54 <ihrachys_> and I don't think it's part of API (and specific to dhcp agent...), so it doesn't directly address the request
14:09:59 <haleyb> i guess OVN doesn't look for such port, but guess it could...
14:10:16 <ihrachys_> but I struggle to see why the request is needed. why would a user want to specify this?
14:10:49 <mlavalle> yeah, what's the use case?
14:10:55 <amotoki> i have a same question as from ihar. what is the motivation of this RFE?
14:11:05 <slaweq> yeah, this device_owner is used by neutron-dhcp-agent but ML2/OVN is using "distributed" port probably
14:11:17 <liushy> Yeah, we have meet many customers want specify the dhcp ip or metadata ip
14:11:44 <ihrachys_> they want it to achieve what?
14:11:50 <opendevreview> Merged openstack/neutron master: Disable mysql gather performance in jobs  https://review.opendev.org/c/openstack/neutron/+/883648
14:12:03 <amotoki> why do they want to specify such IPs?
14:12:49 <liushy> And in any cases, we have always update the ip of metadata port, right?
14:13:42 <slaweq> metadata port, why?
14:13:44 <ihrachys_> liushy I don't follow. what do you mean we update the ip of metadata port? it's created when network is initialized and in general it's not touched.
14:15:53 <ralonsoh> so liushy, what is the rationale behind this RFE? why your customers need to "move" this IP addresses?
14:18:02 <ralonsoh> hello?
14:18:32 <liushy> In any cases, the first ip of subnet is config on switch
14:19:13 <amotoki> liushy: if so, you can define allocation_pools for a subnet not to use the first IP of the subnet
14:19:23 <ralonsoh> exactly
14:19:28 <slaweq> amotoki++
14:20:32 <ralonsoh> does it solve your issue? skipping this IP address from the IPAM pool?
14:20:47 <ralonsoh> (except that you manually assign the IP address to a port)
14:21:27 <slaweq> actually in Your case if You would assign different IP to the dhcp port, then Your "first" ip from the subnet can be allocated to some vm
14:21:38 <slaweq> so You will just move problem somewhere else, not solve it
14:21:52 <slaweq> and using proper allocation pool in neutron can solve it permanently
14:22:48 <liushy> Ok
14:23:31 <ralonsoh> cool, please explore this alternative. I'll update the LP bug with amotoki's proposal
14:23:49 <mlavalle> ++
14:24:06 <ralonsoh> thanks liushy
14:24:21 <ralonsoh> let's move then to the next topic
14:24:35 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/2019960
14:24:39 <ralonsoh> [RFE] Can't protect the "default" security group from regular users
14:24:49 <ralonsoh> I don't know if Paolo is in this channel now
14:24:56 <slaweq> I know this topic
14:25:03 <ralonsoh> slaweq, please go on then
14:25:29 <slaweq> ok, all started in the ML thread few days ago
14:25:54 <slaweq> author of this bug wanted to have policy which will not allow regular users to change SG rules in "default" SG
14:26:19 <slaweq> we are treating "default" SG in kind of special way, it's created for every project
14:26:29 <slaweq> and that can be valid use case
14:26:59 <slaweq> problem is that currently we can't configure even custom API policies for SG rules base on "name" of the SG, which is parent for the SG rule
14:27:38 <slaweq> I described it in https://lists.openstack.org/pipermail/openstack-discuss/2023-May/033719.html
14:27:54 <slaweq> it's the same thing like using "network:shared" field for e.g. ports or subnets
14:28:06 <slaweq> we are doing that but it required special treat in the code
14:28:45 <ralonsoh> in this case I would avoid this special treatment in the code, I would prefer to introduce a bool field (read-only) in the SG rule object
14:28:48 <slaweq> now the question is - do we want to introduce yet another "special" handling, this time for "security_group:name" attribute so it will be possible to use it in policies for SG rules
14:29:44 <ralonsoh> ^ no, I prefer a new field in the SG rule object, filtered as other field with a rule
14:30:18 <slaweq> ralonsoh something like "sg_default: True/False" in the SG rules?
14:30:21 <slaweq> or what?
14:30:24 <ralonsoh> yes
14:30:31 <ralonsoh> is_sg_default
14:30:41 <ralonsoh> a SG rule can be created or deleted
14:31:02 <ralonsoh> when the SG rule is created, the server will read the SG default flag and copy it to the SG rule
14:31:15 <ralonsoh> that will avoid the special treatment
14:31:40 <slaweq> yes, that way You will be able to use directly this new attribute in the api policies
14:31:55 <ihrachys> can it not be generated synthetically by neutron api layer? no need to store it I think.
14:32:25 <slaweq> ihrachys I think that that was the idea
14:32:27 <ralonsoh> that implies doing a second query every time we retrieve a SG rule
14:32:34 <slaweq> it can be calculated "in flight"
14:32:40 <ralonsoh> yes but with a cost
14:33:48 <ralonsoh> hmmm maybe we can, in the SG rule OVO, implement that query to the SG.is_default column
14:33:57 <ihrachys> optimize your query if that's a concern... storing has its own cost (not just in bytes, but keeping consistency, migrating db etc.)
14:34:51 <slaweq> I think that this is good idea
14:35:16 <ralonsoh> maybe we can use a back reference, adding the is_default value of the SG register in the SG rule OVO (that is a SQL view, in a nutshell)
14:35:58 <ralonsoh> ok, that's something technical
14:36:18 <ralonsoh> let's vote first if this RFE (the goal) is approved
14:36:50 <slaweq> +1 for that RFE and for ralonsoh's proposal how to solve it
14:36:57 <ralonsoh> do you agree with having a way to limit the SG rules modification belonging to the default SG?
14:37:39 <amotoki> +1 it sounds a reasnable request to me
14:37:39 <mlavalle> +1
14:38:13 <ralonsoh> haleyb, ?
14:38:25 <haleyb> +1
14:38:40 <ralonsoh> ykarel, are you part of the drivers team? I think so
14:38:55 <ralonsoh> is just to have more votes
14:39:06 <ralonsoh> because I don't present this RFE, I can vote
14:39:10 <ralonsoh> +1 from me
14:39:36 <ihrachys> +0 from me!
14:39:42 <ralonsoh> hehehe
14:39:48 <ralonsoh> thank you all
14:39:57 <ralonsoh> I think this request is reasonable
14:40:04 <ralonsoh> I'll try to implement a POC ASAP
14:40:10 <ralonsoh> I'll update the LP bug
14:40:17 <ralonsoh> something else you want to discuss?
14:41:13 <ralonsoh> PLEASE: kind (maybe not so kind) reminder to review the specs!!
14:41:21 <ralonsoh> have a nice weekend
14:41:26 <ralonsoh> #endmeeting