| opendevreview | Erik Olof Gunnar Andersson proposed openstack/neutron master: Add initial tests for the Designate DNS backend https://review.opendev.org/c/openstack/neutron/+/848424 | 00:48 |
|---|---|---|
| opendevreview | Erik Olof Gunnar Andersson proposed openstack/neutron master: Add initial tests for the Designate DNS backend https://review.opendev.org/c/openstack/neutron/+/848424 | 00:50 |
| opendevreview | Merged openstack/neutron master: Fix remaining typos in comments and tests https://review.opendev.org/c/openstack/neutron/+/848839 | 03:50 |
| opendevreview | Karthik S proposed openstack/neutron master: WIP: Add min bandwidth support to ml2-ovn https://review.opendev.org/c/openstack/neutron/+/842292 | 05:46 |
| opendevreview | Karthik S proposed openstack/neutron master: WIP: Add min bandwidth support to ml2-ovn https://review.opendev.org/c/openstack/neutron/+/842292 | 05:50 |
| sahid | morning all | 07:30 |
| sahid | I'm trying to execute dsvm-fullstack using this command `PBR_VERSION=1.2.3 tox -e dsvm-fullstack test_l3_agent` | 07:31 |
| sahid | The tests are executed but I have this assertion: AssertionError: backend 'mysql' unavailable | 07:31 |
| sahid | I have mysql install and its client, It's a VM running devstack actually, so I'm wondering to know if someone as already seen this error? | 07:33 |
| ralonsoh | because you need to install first the DB backends | 07:35 |
| ralonsoh | sahid, execute ./neutron/tools/configure_for_func_testing.sh <devstack_patch> | 07:39 |
| ralonsoh | path* | 07:40 |
| sahid | oh interesting, trying... :-) thank you ralonsoh | 07:47 |
| * sahid should have read TESTING.rst ... | 07:47 | |
| sahid | I have executed the command `./tools/configure_for_func_testing.sh:main:351 echo 'Phew, we'\''re done!' ` | 08:08 |
| sahid | Phew, we're done! | 08:08 |
| sahid | even with that I still have the issue | 08:08 |
| opendevreview | Lajos Katona proposed openstack/neutron master: [sqlalchemy-20] Remove retry decorator from update_floatingip_status https://review.opendev.org/c/openstack/neutron/+/848701 | 08:21 |
| frickler | sahid: I have also given up on trying to get fullstack to run locally. If you want to investigate further what is the difference from the CI setup, you could ask to get access to a held CI node. it would be really helpful if the instructions could be updated in such a way that they work | 08:50 |
| lajoskatona | frickler, sahid: I have a VM in which I run fullstack, and few weeks ago it worked, if you have any update on the test doc would be really good, as it was updated years ago I think | 08:56 |
| lajoskatona | sahid: I execute configure_for_func_testing with something like this: export VENV=dsvm-fullstack; export IS_GATE=False; tools/configure_for_func_testing.sh ~/devstack/ -i | 08:58 |
| lajoskatona | sahid: IS_GATE=False switches to install databases also (https://opendev.org/openstack/neutron/src/branch/master/tools/configure_for_func_testing.sh#L332 ) | 08:59 |
| lajoskatona | sahid: the doc also mentiones it: https://docs.openstack.org/neutron/latest/contributor/testing/testing.html#id4 | 08:59 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Add release note for OVN "requested-chassis" feature https://review.opendev.org/c/openstack/neutron/+/849082 | 09:52 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Remove workaround for LP#1767422 https://review.opendev.org/c/openstack/neutron/+/848312 | 10:07 |
| *** sean-k-mooney1 is now known as sean-k-mooney | 10:10 | |
| sahid | lajoskatona, frickler thanks a lot for you returns | 10:50 |
| sahid | frickler: interesting point to get qccess to the CI directly thanks a lot I will keep that in mind | 10:51 |
| sahid | lajoskatona: Ok I'm rebuilding a new VM and will try | 10:51 |
| sahid | for sure I will update the doc if I found any diff, no worries | 10:52 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Remove import of 'imp' module https://review.opendev.org/c/openstack/neutron/+/842450 | 11:30 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [WIP] Script to manually remove duplicated port bindings https://review.opendev.org/c/openstack/neutron/+/846422 | 11:31 |
| lajoskatona | sahid: +1, thanks, we are happy for any feedback :-) | 11:39 |
| sahid | lajoskatona, frickler Ok I was able to make it working without too much pain using a french VM and devstack. The only thing that failed was that the process was looking for something in /requierements but the repository was not yet cloned. I had to clone it under /opt/stack and re-execute the command | 13:07 |
| sahid | I will try to investigate that later to double check if there is really a need and try to fix that if possible | 13:07 |
| sahid | s/french/fresh :-) | 13:08 |
| lajoskatona | sahid: cool | 13:26 |
| lajoskatona | mnaser: Hi, we have a vpnaas related RFE for today's drivers meeting: https://bugs.launchpad.net/neutron/+bug/1979044 ([RFE] Adding the "rekey" parameter to the api for strongswan like "dpd_action" ) | 13:26 |
| lajoskatona | mnaser: would be nice if you could join us, perhaps you have some opinion on it, or have some thoughts for the feature | 13:27 |
| mnaser | lajoskatona: ah cool just ping me when that discussion comes up and I’ll gather context now :) | 13:28 |
| lajoskatona | mnaser: thanks, 1400 UTC when we start, 9 minutes from now | 13:51 |
| lajoskatona | mnaser: and that is the first topic for today, so we won't waste your time :-) | 13:54 |
| *** dasm|off is now known as dasm | 13:56 | |
| lajoskatona | #startmeeting neutron_drivers | 14:00 |
| opendevmeet | Meeting started Fri Jul 8 14:00:09 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 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:00 |
| opendevmeet | The meeting name has been set to 'neutron_drivers' | 14:00 |
| lajoskatona | o/ | 14:00 |
| mlavalle | o/ | 14:00 |
| slaweq | o/ | 14:00 |
| njohnston | o/ | 14:00 |
| ralonsoh | hi | 14:00 |
| obondarev | hi. Just realised I missed PTL meeting, sorry | 14:01 |
| haleyb | hi | 14:01 |
| amotoki | hi | 14:01 |
| lajoskatona | Ok, I think we can start | 14:03 |
| lajoskatona | The first RFE for today: | 14:03 |
| lajoskatona | [RFE] Adding the "rekey" parameter to the api for strongswan like "dpd_action" (#link https://bugs.launchpad.net/neutron/+bug/1979044) | 14:03 |
| lajoskatona | it is for VPNasS, so I asked mnaser to come and tell his opinion if he as some time | 14:04 |
| mlavalle | yeah, mnaser's is a very relevant opinion. amotoki's is too | 14:05 |
| mnaser | I looked at it and I think it’s actually a pretty good idea however I’m not sure if I have Amelia time to be able to look into implementing this but I’d be happy to review somebody makes a chance address | 14:05 |
| lajoskatona | mnaser: thanks | 14:05 |
| obondarev | first dumb question that I have is: if it's device specific, can't device driver take care of setting needed 'rekey' value | 14:06 |
| amotoki | what I am not sure is 'rekey' proposed here should be determined by neutron API users | 14:06 |
| lajoskatona | That is my feeling also, that extending the API to have a new key: rekey is a good idea | 14:06 |
| amotoki | or it depends on devices or vpn situations | 14:06 |
| lajoskatona | obondarev, amotoki: good point | 14:08 |
| obondarev | from description it seems it depends on the device, and that strongswan is not aware of underlying device | 14:08 |
| obondarev | *strongswan driver | 14:08 |
| obondarev | and that's where a user should step in and advice the driver | 14:09 |
| opendevreview | Merged openstack/neutron-dynamic-routing master: Consume BGP service plugin queue in RPC workers https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/842383 | 14:09 |
| obondarev | so maybe the driver itself should have the ability to identify the device somehow? | 14:09 |
| slaweq | obondarev++ | 14:10 |
| lajoskatona | transparently for the enduser? | 14:10 |
| amotoki | AFAIK rekey itself is not specific to strongswan. other VPN products also support it. | 14:10 |
| obondarev | yes, not sure about the technical possibility however | 14:11 |
| amotoki | but I am still not sure it should be visible to VPNaaS users | 14:11 |
| mnaser | Im looking at https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNTunnels.html | 14:12 |
| mlavalle | ahhh, looking at the alternative... always wise | 14:13 |
| mnaser | It seems like they don’t provide option to disable it | 14:13 |
| mnaser | GCP doesn’t either | 14:15 |
| mnaser | So I feel like it would be wise to ask or understand why the user wants to do this | 14:15 |
| amotoki | yeah, it is not a good idea to disable rekey in general | 14:16 |
| mnaser | I guess maybe a poor implementation on the other side… | 14:16 |
| obondarev | ++ and if there is a possibility to identify the needed value from within the strongswan driver | 14:17 |
| amotoki | it looks better to ask the rfe submitter more detail on what situations requires rekey=no | 14:18 |
| lajoskatona | ok, so this is not something that user should set on API, but more a technical question which the driver can determine and set, am I right? | 14:19 |
| amotoki | I think so | 14:19 |
| obondarev | that's my vision also | 14:19 |
| amotoki | if it depends on vpn peers, we may need to pass rekey parameter to a driverr like strongswan but perhaps we first need to clarify when such situation happens | 14:21 |
| lajoskatona | ok | 14:22 |
| -amotoki- (my memory on vpn is not so fresh. it was from several years ago :p) | 14:22 | |
| lajoskatona | mnaser: shall I ask you to write down to the RFE what information should be necessary as my VPN background is very weak :-( | 14:23 |
| mnaser | sure, I can update the issue asking that | 14:24 |
| lajoskatona | manser: thanks for the help | 14:24 |
| lajoskatona | And thanks everybody for the discussion | 14:24 |
| lajoskatona | If there is no more comments for this RFE we can move on to the next one | 14:25 |
| lajoskatona | [RFE] Firewall Group Ordering on Port Association (#link https://bugs.launchpad.net/neutron/+bug/1979816) | 14:25 |
| lajoskatona | This one comes from a security bug, which I made public, after long discussion under it, and agreeing that we don't need to have it private: | 14:26 |
| lajoskatona | https://bugs.launchpad.net/neutron/+bug/1978497 | 14:26 |
| lajoskatona | if I understand well the behaviur here is already documented in the original spec for FWaaS | 14:27 |
| opendevreview | Merged openstack/neutron master: [sqlalchemy-20] Remove retry decorator from update_floatingip_status https://review.opendev.org/c/openstack/neutron/+/848701 | 14:28 |
| opendevreview | Merged openstack/neutron master: Remove workaround for LP#1767422 https://review.opendev.org/c/openstack/neutron/+/848312 | 14:28 |
| lajoskatona | somewhere here: https://specs.openstack.org/openstack/neutron-specs/specs/newton/fwaas-api-2.0.html#multiple-firewall-policies | 14:28 |
| ralonsoh | that's the point: does it depends on the order of those groups or in evaluating the security for a specific traffic (that means, evaluating all rules)? | 14:30 |
| ralonsoh | according to the documentation: This spec defines that packets will be allowed if any one of the firewall groups associated with that Neutron port allows the packet. | 14:30 |
| ralonsoh | that means you need to evaluate all rules (or at least find one allowing this traffic) | 14:31 |
| slaweq | but it also says that in future it should be changed and ordering should be added | 14:32 |
| slaweq | I think that current RFE is exactly about that | 14:32 |
| mlavalle | meaning that future has arrived | 14:32 |
| ralonsoh | so perfect then (just one concern: if implemented, some environments will change their current behaviour) | 14:33 |
| mlavalle | yeap | 14:33 |
| mlavalle | it should go with a release note | 14:34 |
| lajoskatona | +1 | 14:34 |
| slaweq | maybe ordering could be optional | 14:34 |
| slaweq | if none of groups would have it, behaviour would stay as it is now | 14:34 |
| slaweq | wdyt? | 14:34 |
| atimmins | Agree on the release note, but fwiw, if an environment is working today, where ordering does not matter, then it would continue to work if ordering was added. | 14:35 |
| mlavalle | slaweq: +++ | 14:35 |
| mlavalle | yeah make it optional | 14:35 |
| obondarev | I'm not sure that currently this behaviour is predictable, according to the rfe it's not | 14:35 |
| amotoki | as of now, we can define the order of rules inside a firewall policy and a point is that a rule can define 'deny' action. | 14:35 |
| ralonsoh | atimmins, you need to guarantee no rule is in conflict with othrs | 14:36 |
| amotoki | what happens if the order of groups are ambiguous | 14:36 |
| amotoki | ? | 14:36 |
| haleyb | isn't it inderminate today? if I have rules that both allow and deny a packet whichever is first wins | 14:36 |
| obondarev | haleyb: ++ | 14:37 |
| ralonsoh | now "allow" should prevail, according to the documentation | 14:37 |
| haleyb | Even if I feel allow should always win | 14:37 |
| atimmins | That's the current behavior. Ordering changes any time a policy is edited, and if denies are present, traffic could start to get blocked unintentionally. | 14:37 |
| haleyb | ralonsoh: and the opposite argument is that deny should prevail, else it's a vulnerability | 14:38 |
| lajoskatona | by optional you mean to add an API extension with a new ordered=True/false option? | 14:38 |
| obondarev | to me current behaviour seems buggy, so should be fixed without any options | 14:39 |
| amotoki | i think there are two directions: one is to improve the behavior to be more determinestic. hte ohter is to introduce ordered=True/false. what do you think? | 14:39 |
| ralonsoh | atimmins, sorry, I'm confused now. Does it means the current behaviour changes with the order? | 14:39 |
| ralonsoh | it shouldn't now | 14:39 |
| ralonsoh | I have the same impression as obondarev. And agree with amotoki to make the current behaviour deterministic, before implementing anything new | 14:41 |
| atimmins | Yes, the spec is not accurate. Changing the order of groups on a port could impact whether traffic is allowed or denied. iptables processes the rules in order. | 14:41 |
| atimmins | This is why there should be an order to groups, just as there is an order to rules within a policy. | 14:41 |
| haleyb | I wonder what OVS does? But I agree making it deterministic is first step | 14:42 |
| lajoskatona | +1 | 14:42 |
| obondarev | the question I have is: should it be ordered, or just 'deny' actions should be of highest priority? | 14:42 |
| obondarev | the question I have is: should it be ordered, or just 'deny' actions should be of highest priority? | 14:43 |
| atimmins | No, this would limit the functionality that iptables provides natively. | 14:43 |
| mlavalle | no, deny should be the default. But once something is defined, it should behave the way the user defined | 14:43 |
| amotoki | obondarev: or another option is to make the behaviro described in the initial spec | 14:44 |
| lajoskatona | that's my understanding and it should be after editing also | 14:44 |
| lajoskatona | amotoki: you mean as "future" work? | 14:44 |
| amotoki | lajoskatona: yes | 14:45 |
| amotoki | but we can discuss what is the right future | 14:45 |
| amotoki | the initial spec is just one idea on multiple fw groups | 14:45 |
| obondarev | so I guess we agree with the RFE/bug and need a spec, right? | 14:46 |
| atimmins | imo, it's far more work to have neutron consolidate/reconcile rules among multiple groups, compared to adding an ordering to the port-group associations. The former could also have unintended consequences. | 14:47 |
| ralonsoh | no sorry, I think we need first to determine if the current behaviour is what is defined in the spec | 14:47 |
| amotoki | lajoskatona: correction: what I mean is the paragraph "This spec defines that packets will be allowed if any one of the firewall groups associated ...." in https://specs.openstack.org/openstack/neutron-specs/specs/newton/fwaas-api-2.0.html#multiple-firewall-policies | 14:47 |
| amotoki | lajoskatona: I do not mean "In future phases, ..." paragraph in the above spec | 14:48 |
| ralonsoh | ^^ this is the key point here that fwaas is "maybe" not honoring | 14:48 |
| amotoki | ralonsoh: +1 | 14:48 |
| lajoskatona | amotoki: ok, thanks | 14:48 |
| obondarev | ralonsoh: agree | 14:48 |
| lajoskatona | ok, so generally the idea is good, but before starting any work the current situation must be checked compared to the original design /spec | 14:50 |
| lajoskatona | and after that we can have a spec for example where the details can be discussed to have the good direction and decisions | 14:51 |
| lajoskatona | Is that correct? | 14:51 |
| mlavalle | +1 | 14:51 |
| ralonsoh | +1 | 14:51 |
| atimmins | I think the original bug report provides sufficient evidence that the original spec is incorrect, but totally fine if others would like to verify. | 14:51 |
| amotoki | lajoskatona: is "the idea" the ordering of groups or does it mean to match the current implemetation with the initial spec? | 14:52 |
| obondarev | atimmins: you mean the spec is incorrect or the implementation? | 14:52 |
| lajoskatona | atimmins: you mean this one: https://bugs.launchpad.net/neutron/+bug/1978497 ? | 14:52 |
| atimmins | Yes, that one | 14:52 |
| atimmins | The statement in the spec is incorrect based on the behavior we see today. | 14:53 |
| lajoskatona | atimmins: than the first step should be to make the implementation in sync with the spec, am I right? | 14:53 |
| atimmins | I find it more desirable to add ordering to the groups | 14:55 |
| atimmins | I'm not immediately aware of how one would make the implementation in sync with the spec, as it is contrary to how traditional ACLs work. | 14:56 |
| lajoskatona | with and API extension like ordered=True? | 14:56 |
| opendevreview | Miro Tomaska proposed openstack/neutron master: [WIP] Need to update unit tests once we agree on implementation! Fix eventlet bug in get_hypervisor_hostname https://review.opendev.org/c/openstack/neutron/+/849122 | 14:56 |
| obondarev | honestly, I'm a bit confused there are 'deny' rules in a "deny until explicitly allowed" concept, by maybe it's just my lack of expertise in this topic | 14:57 |
| * mlavalle has to leave to a doctor's appointment (routine check). On demand agenda topic can wait to Neutron's meeting on Tuesday | 14:57 | |
| lajoskatona | malavalle: ack, thanks for joining | 14:57 |
| atimmins | By adding a "position" column to the relevant table, we can provider the ordering. Maybe if the value is Null, then the behavior stays the same? IE. order for that groups does not matter? | 14:58 |
| ralonsoh | atimmins, please, before adding anything new to a project, let's fix what does not match with the current spec | 14:58 |
| ralonsoh | this is even more important if security is related | 14:59 |
| lajoskatona | ralonsoh: +1 | 14:59 |
| amotoki | ralonsoh: +1 | 14:59 |
| slaweq | ++ | 14:59 |
| atimmins | I'm proposing the best way to fix the current spec is by implementing group ordering. | 15:00 |
| lajoskatona | ok, so let's write sown in the current RFE, what is that is not working in the current implementation as it is written in the spec | 15:00 |
| lajoskatona | atimmins: thanks for it | 15:01 |
| atimmins | No problem, thanks everyone | 15:01 |
| lajoskatona | perhaps the best would be to open a spec where in review the discussion is quite easy to go in the agreed direction | 15:01 |
| lajoskatona | We reached the end of the hour, wdyt of a spec for this and countinue the discussion under it with more details what is the need compared to the original spec? | 15:02 |
| ralonsoh | perfect | 15:02 |
| amotoki | +1 | 15:02 |
| slaweq | +! | 15:02 |
| slaweq | +1 | 15:02 |
| obondarev | +1 | 15:03 |
| lajoskatona | ok, thanks for the discussion, I will update the RFE, and let's see the spec :-) | 15:03 |
| lajoskatona | #endmeeting | 15:03 |
| opendevmeet | Meeting ended Fri Jul 8 15:03:46 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:03 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/neutron_drivers/2022/neutron_drivers.2022-07-08-14.00.html | 15:03 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/neutron_drivers/2022/neutron_drivers.2022-07-08-14.00.txt | 15:03 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/neutron_drivers/2022/neutron_drivers.2022-07-08-14.00.log.html | 15:03 |
| ralonsoh | have a nice weekend | 15:03 |
| lajoskatona | Bye, have a nice weekend ! | 15:03 |
| slaweq | o/ | 15:03 |
| amotoki | thanks everyone. have a nice weekend! | 15:04 |
| obondarev | o/ | 15:04 |
| amotoki | obondarev: regarding on your question on 'deny' rules, 'deny' rules allows us to define firewall rules which allow all in general but deny traffic from this range. It is not easy to define such rules in security groups | 15:09 |
| amotoki | this is what most ACLs in network switches support. | 15:10 |
| obondarev | amotoki: got it, thanks! | 15:11 |
| amotoki | obondarev: yw | 15:11 |
| *** dasm is now known as dasm|off | 21:36 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!