14:00:14 <lajoskatona> #startmeeting neutron_drivers
14:00:14 <opendevmeet> Meeting started Fri Aug 19 14:00:14 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:14 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:14 <opendevmeet> The meeting name has been set to 'neutron_drivers'
14:00:17 <mlavalle> o/
14:00:18 <lajoskatona> Hi!
14:00:22 <ralonsoh> hi
14:00:30 <obondarev> hi
14:00:52 <slaweq> hi
14:02:32 <lajoskatona> As I see we have quorum
14:02:35 <lajoskatona> Let's start
14:02:44 <haleyb> hi
14:02:46 <lajoskatona> We have 2 RFEs for today
14:02:56 <lajoskatona> [RFE] Add possibility to define default security group rules (#link https://bugs.launchpad.net/neutron/+bug/1983053 )
14:03:31 <slaweq> that's proposed by me
14:03:33 <lajoskatona> I think we discussed something like this but I was not able to find it in logs :-(
14:04:05 <slaweq> during one of the PTGs I think we discussed that default rules aren't the greates
14:04:24 <slaweq> but conclusion was to not change them to not break backward compatibility
14:05:02 <lajoskatona> ahh, ok so it was one of the PTGs
14:05:05 <slaweq> but recently we discussed that internall again and we think that it could be made better than it's now with hardcoded rules
14:05:31 <slaweq> IMO the best way would be to add API resource like "default SG rule"
14:05:59 <slaweq> and those would be stored in Neutron database and used for every new SG
14:06:07 <slaweq> instead of currently used hardcoded rules
14:06:18 <slaweq> only admin would be able to change those default rules
14:06:27 <obondarev> sorry, for every new SG or project
14:06:30 <obondarev> ?
14:06:39 <ralonsoh> good question
14:06:44 <lajoskatona> project as I understand
14:06:54 <slaweq> obondarev there are 2 things here
14:07:09 <slaweq> 1. Default SG which is created automatically for every new project
14:07:20 <slaweq> that one have always 4 rules added automatically
14:07:34 <obondarev> yep
14:07:40 <slaweq> 2. Every other SG created by user - this one has 2 rules added by Neutron automatically
14:08:14 <slaweq> so, we can add possibility to define by admin new rules for both of those types of security groups
14:08:43 <ralonsoh> where/how those generic default rules are created?
14:10:29 <haleyb> Two questions - 1) Why can't this just be a post project create task by the admin, which could work today?  2) Is the user not allowed to change these rules?
14:10:43 <slaweq> https://github.com/openstack/neutron/blob/b551516e30ad7ccd38a0ef651741c307fa4e8216/neutron/db/securitygroups_db.py#L80
14:10:43 <obondarev> I guess these
14:10:58 <obondarev> sorry, disregard please
14:10:59 <slaweq> this is method which creates security group and adds rules to it
14:11:02 <ralonsoh> no no I mean, how do you propose it?
14:11:21 <ralonsoh> how do you propose to create those default rules?
14:11:26 <slaweq> haleyb users can remove/change those rules
14:11:31 <slaweq> but:
14:12:04 <slaweq> a) we had some requests from customers that admin would like to define for users some other set of the rules added automatically to the new SGs
14:12:38 <haleyb> So not just to the default SG when the project is created?
14:12:43 <slaweq> b) default SG rules which are added today aren't great, we know that rules with remote_group_id aren't scale well,
14:13:41 <slaweq> haleyb I think we can allow to define set of rules which will be added for each new SG and some "special" set of the rules which will be added also to each new "Default" SG
14:13:48 <slaweq> that shouldn't be problem
14:14:17 <haleyb> Ok, the bug only mentions the default SG is why I ask
14:14:55 <lajoskatona> Personally I tend also to think that this can be solved neatly with hot templates or other tools, but can accept that this will be better for customers
14:16:02 <lajoskatona> perhaps Neutron API is good place for such customization and default settings for sec-groups
14:16:14 <slaweq> haleyb sorry, it was probably my "shortcut" when I was writing RFE
14:18:40 <lajoskatona> Basically I am ok with this RFE, but I think we need a spec to see the details
14:18:45 <haleyb> slaweq: is there much of a use case for the non-default SG? for example, if I create a new SG for say secure access, do we want extra rules added there?
14:19:26 <haleyb> I could see adding icmp and ssh to default since we all do it first thing anyways, but that doesn't need a code change, just a heat template
14:19:44 <slaweq> haleyb not everyone is using heat
14:20:13 <slaweq> I know it can be automated with some script
14:20:26 <slaweq> but we had such request to allow such modification
14:20:54 <slaweq> and IMO it's reasonable request as it would be better instead of hardcoded things
14:21:18 <haleyb> slaweq: well, it could even just be in my create-project.sh script as a post-create step like you mention. just playing devils advocate
14:22:44 <obondarev> my 2 cents: I also know customers that are suffering from a "remote_group_id" rules in default SG
14:23:55 <ralonsoh> yeah, I'm ok with the feature (needed by some customers) but I waiting for the implementation details
14:23:59 <mlavalle> yeah, that's a scuge
14:24:09 <mlavalle> scurge
14:25:00 <lajoskatona> So let's have a spec and see the details for it
14:25:09 <mlavalle> +1
14:25:13 <slaweq> of course I will write spec with proposed API changes first if this will be accepted
14:25:15 <haleyb> obondarev: ack, and this is maybe a more attractive option of doing this spec to not create those rules
14:25:33 <haleyb> if it was just adding rules it would be different (to me)
14:26:52 <lajoskatona> Ok, let's vote than to see if we are ok with the RFE with the condition of a spec
14:26:56 <lajoskatona> +1 from me
14:27:05 <ralonsoh> +1
14:27:17 <mlavalle> +1
14:27:18 <obondarev> +1
14:27:33 <haleyb> +1
14:28:06 <lajoskatona> ok, thanks, I will update the RFE
14:28:21 <lajoskatona> The 2nd one:
14:28:25 <lajoskatona> [rfe][fwaas]support standard_attrs for firewall_group (#link https://bugs.launchpad.net/neutron/+bug/1986906 )
14:28:53 <slaweq> thank You
14:30:00 <lajoskatona> As I see this RFE is quite simple: let's have standard attrs for fwaas_groups
14:31:32 <slaweq> I agree with lajoskatona and I have no objections for it
14:31:57 <ralonsoh> I'm ok too, looks an easy change
14:32:04 <obondarev> yeah, looks pretty straightforward, no questions from me
14:33:01 <lajoskatona> mlavalle, haleyb: what do you think?
14:33:23 <mlavalle> +1
14:33:38 <mlavalle> pretty straightforward
14:34:02 <mlavalle> we don't need a spec, do we?
14:34:12 <mlavalle> just kidding :-)
14:34:16 <lajoskatona> :-)
14:34:17 <haleyb> +1 as this should be on most objects
14:34:40 <lajoskatona> Ok, I will update this RFE also, thanks for discussing it :-)
14:34:53 <lajoskatona> #topic On Demand Agenda
14:35:05 <lajoskatona> Do you have anything more which we can discuss ?
14:35:16 <slaweq> nothing from me
14:35:26 <mlavalle> nothing from me
14:35:26 <atimmins> hey all - looking for another review of https://review.opendev.org/c/openstack/neutron-specs/+/851607
14:35:27 <obondarev> nope
14:35:54 <mlavalle> atimmins: I'll review it today
14:36:00 <atimmins> Thanks!
14:36:23 <slaweq> atimmins added to my review list
14:36:33 <slaweq> but I will check it next week probably
14:36:37 <lajoskatona> atimmins: I will check it also (perhaps early next week)
14:36:48 <lajoskatona> If nothing more we can close the meeting
14:36:55 <lajoskatona> #endmeeting