| opendevreview | Ghanshyam proposed openstack/os-vif master: Update python classifier in setup.cfg https://review.opendev.org/c/openstack/os-vif/+/904613 | 03:15 |
|---|---|---|
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: WIP == DNM == [OVN] Implement OVN agent metadata extension https://review.opendev.org/c/openstack/neutron/+/898238 | 08:34 |
| opendevreview | Darin Chakalov proposed openstack/python-neutronclient master: Implement address groups support in python-neutronclient https://review.opendev.org/c/openstack/python-neutronclient/+/904703 | 09:35 |
| opendevreview | dongdong proposed openstack/neutron-fwaas master: Set the correct firewall group status when the router is updated https://review.opendev.org/c/openstack/neutron-fwaas/+/904317 | 09:43 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron-tempest-plugin master: Add router check, subnet attached gateway IP update or deletion https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/904710 | 10:06 |
| ralonsoh | folks, if you have stable core permissions, please check https://review.opendev.org/c/openstack/neutron/+/904498 | 10:20 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Forbid the subnet gateway IP if a router interface is attached https://review.opendev.org/c/openstack/neutron/+/904713 | 10:26 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron-tempest-plugin master: Add router check, subnet attached gateway IP update or deletion https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/904710 | 10:26 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Forbid the subnet gateway IP deletion if a router interface is attached https://review.opendev.org/c/openstack/neutron/+/904713 | 10:26 |
| opendevreview | Merged openstack/neutron stable/2023.1: Metadata: handle process exceptions https://review.opendev.org/c/openstack/neutron/+/893775 | 10:44 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Forbid the subnet gateway IP deletion if a router interface is attached https://review.opendev.org/c/openstack/neutron/+/904713 | 11:31 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron stable/2023.2: Handle creation of Port_Binding with chassis set https://review.opendev.org/c/openstack/neutron/+/904715 | 11:36 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron stable/2023.1: Handle creation of Port_Binding with chassis set https://review.opendev.org/c/openstack/neutron/+/904716 | 11:40 |
| andreykurilin | ralonsoh: hi! Do you have a couple of minutes to discuss neutronclient state? Context: https://review.opendev.org/c/openstack/python-neutronclient/+/904703 | 11:48 |
| ralonsoh | andreykurilin, sure | 11:56 |
| ralonsoh | https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/KTTBW2DNGELWHKOXMMBAQYTKKQDX2VNF/ | 11:57 |
| andreykurilin | ralonsoh: yup, I saw this and contribution section of docs also notes the same https://opendev.org/openstack/python-neutronclient/src/branch/master/doc/source/index.rst#contributor-guide | 12:01 |
| andreykurilin | At the same time https://review.opendev.org/c/openstack/python-neutronclient/+/904703 does not touch neutron CLI, it extends neutron python bindings which is not deprecated yet | 12:01 |
| ralonsoh | what project is using it? | 12:02 |
| andreykurilin | Horizon for example :) | 12:02 |
| ralonsoh | andreykurilin, but is this feature needed by another feature in Horizon? | 12:05 |
| ralonsoh | where are you planning to use this? | 12:05 |
| andreykurilin | Darin, the author of the change, is working on fixing Horizon to display security groups in case of address group usage. Currently, the ‘target’ of sec group is displayed there as 0.0.0.0/0 for all address groups which is quite misleading | 12:07 |
| ralonsoh | andreykurilin, please, talk to Lajos Katona (the author of https://review.opendev.org/c/openstack/horizon/+/891205) in order to know if that could be supported "as-is" with the OSC | 12:09 |
| ralonsoh | I'll add him to the neutronclient patch | 12:09 |
| ralonsoh | we are moving all bindings to OSC and moving the project clients to OSC | 12:10 |
| ralonsoh | adding new features to neutronclient is going in the opposite direction | 12:10 |
| andreykurilin | oh, this sounds promising | 12:11 |
| andreykurilin | thanks | 12:11 |
| ralonsoh | in any case, please raise this question in the next neutron meeting | 12:11 |
| ralonsoh | one sec | 12:11 |
| ralonsoh | I'll add this topic to the on-deman agenda | 12:11 |
| ralonsoh | done --> https://wiki.openstack.org/wiki/Network/Meetings#On_Demand_Agenda | 12:13 |
| andreykurilin | Thank you | 12:14 |
| andreykurilin | ralonsoh: can you point me the place where I can find the schedule of meetings? | 12:15 |
| andreykurilin | https://meetings.opendev.org/#Neutron_Team_Meeting | 12:15 |
| ralonsoh | https://meetings.opendev.org/#Neutron_Team_Meeting | 12:15 |
| ralonsoh | yes, right | 12:15 |
| andreykurilin | Ok, I’ll be there. Thanks for your input! | 12:16 |
| andreykurilin | ralonsoh, one more question: Who is the better to bother about neutron policies stuff (inner implementation neutron-server -> neutron-lib)? :) | 12:18 |
| ralonsoh | any neutron core, what's the question? | 12:19 |
| andreykurilin | We have kolla-ansible deployment and use some custom neutron policies. Everything works great except logging. Neutron-server logs include a warning message `Policies <list-of-neutron’s-overriden-policies> reference a rule that is not defined`. Further debugging showed that this message comes from neutron-lib code. As far as I understand, the problem is that neutron and neutron-lib code read the same policies.yaml file (as | 12:25 |
| andreykurilin | a part of neutron-server). neutron-lib finds overridden rules of neutron-server and, as it knows nothing about them, it complains about them. | 12:25 |
| andreykurilin | neutron is of 2023.1 release | 12:30 |
| andreykurilin | https://github.com/openstack/oslo.policy/blob/master/oslo_policy/policy.py#L703C12-L705 the origin of the warning | 12:35 |
| andreykurilin | And simplified snippet for reproducing the issue https://xsnippet.org/H3jpRsCi | 12:44 |
| opendevreview | Merged openstack/neutron master: Handle creation of Port_Binding with chassis set https://review.opendev.org/c/openstack/neutron/+/903796 | 13:21 |
| ralonsoh | andreykurilin, sorry, I don't understand the problem you have. neutron-lib is just a module used by Neutron (and many other projects) | 14:25 |
| ralonsoh | n-lib is not checking anything, the Neutron server is | 14:25 |
| ralonsoh | what is the problem you have in your env? | 14:25 |
| ralonsoh | andreykurilin, ok, maybe the problem, as you pointed out, is the duplication of this variable *ENFORCER | 14:31 |
| ralonsoh | please, can you reproduce that with DEBUG logs and send the output? | 14:31 |
| ralonsoh | and the policies yaml | 14:31 |
| andreykurilin | ralonsoh: When neutron-server starts, it initializes neutron-lib’s policy enforcer at some stages. As far as I remember (I was debugging this several months ago, so I could be wrong), it is because neutron-server uses context object from n-lib, and n-lib enforcer is used to check whether the requester is admin or not. As the neutron-lib enforcer is initialised as a part of the neutron-server process, it uses the same | 14:41 |
| andreykurilin | config file and the same policy.yaml file. N-lib enforcer finds neutron-server rules inside of policy.yaml (as it is shared), those rules may re-use neutron-server’s default rules, but as neutron-lib knows nothing about neutron-server default rules, it raises a warning log message. Everything works (default and overridden rules), but this warning message is quite misleading | 14:41 |
| andreykurilin | policy.yaml https://xsnippet.org/lGseu215 and warning message https://xsnippet.org/Ku6nJ9Pi | 14:47 |
| ralonsoh | andreykurilin, ok, I'll open a LP bug right now | 14:54 |
| mtomaska | hello folks. Is it ok to merge this patch. I need it for some downstream work https://review.opendev.org/c/openstack/neutron/+/903572. thank you! | 15:31 |
| andreykurilin | ralonsoh: so this sounds like a bug for you, good. Thank you! :) | 15:41 |
| ralonsoh | I'm testing it now | 15:41 |
| ralonsoh | andreykurilin, what is SystemReader? we have these roles: member, admin, service and adsvc in Neutron | 15:46 |
| ralonsoh | but not SystemReader | 15:46 |
| ralonsoh | and reader | 15:46 |
| ralonsoh | so 5 roles | 15:46 |
| andreykurilin | ralonsoh: This is our custom role. As it is role (not rule), a ‘dynamic’ thing, oslo.policy does not validate it as a part of initialisation, it is used only to comparison with the data from the token as far as I know | 15:51 |
| ralonsoh | oslo policy is sending that to the "undefined_checks" variable | 15:52 |
| ralonsoh | in oslo_policy.policy.Enforcer.check_rules | 15:53 |
| ralonsoh | so that's what is happening | 15:53 |
| andreykurilin | it does it only for n-lib. Neutron-server enforcer passes it | 15:53 |
| andreykurilin | * passes it during my testing :) | 15:54 |
| andreykurilin | https://github.com/openstack/oslo.policy/blob/master/oslo_policy/policy.py#L818-L821 _undefined_check validates only RuleCheck. RoleCheck does not inherit RuleCheck https://github.com/openstack/oslo.policy/blob/master/oslo_policy/_checks.py#L254-L282 so it should be skipped as a part of undefined_check | 15:56 |
| ralonsoh | andreykurilin, actually it is failing in "rule:admin_only" | 16:04 |
| ralonsoh | because this rule does not exist when the n-lib enforcer is loaded | 16:04 |
| andreykurilin | ralonsoh: I’m not Oslo-policy expert, but I think n-lib enforcer is loading only with 3 rules https://github.com/openstack/neutron-lib/blob/master/neutron_lib/policy/_engine.py#L33-L46 and ‘rule:admin_only’ is never can be visible there until it is added to policy.yaml | 16:07 |
| ralonsoh | yes, these are the base rules | 16:08 |
| ralonsoh | but I don't know why are we loading the enforcer at this point | 16:09 |
| ralonsoh | this is coming from https://review.opendev.org/c/openstack/neutron-lib/+/887191 | 16:09 |
| ralonsoh | tomorrow I'll ping slaweq for that, but I'll continue debugging it today evening | 16:10 |
| andreykurilin | ralonsoh: thank you so much. Please ping me if you need any additional info, help for debugging, etc. | 16:12 |
| opendevreview | Sebastian Lohff proposed openstack/neutron master: Prevent ext subnet GW IP being allocated as FIPs https://review.opendev.org/c/openstack/neutron/+/904783 | 18:11 |
| jamesdenton__ | Hi folks. Question for OVN folks... I've got 2 Antelope environments exhibiting an issue where (at least) arp and icmp traffic is being filtered/dropped when egressing an ovnmeta namespace. The network is a VLAN provider network, for what it's worth. The ARP cache in the ovnmeta namespace is populated when other hosts in the VLAN send GARPs, but when those age out, any subsequent ARP from the tap interface in the namespace is not seen | 21:01 |
| jamesdenton__ | outside of the namespace (ie. on the physical interface connected to br-ex). Hopefully that makes sense... | 21:01 |
| opendevreview | Miguel Lavalle proposed openstack/neutron master: Router flavors and service type for OVN https://review.opendev.org/c/openstack/neutron/+/883988 | 23:52 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!