Hi,
This is the Neutron bug report from January 3rd to 10th.
Critical:
* https://bugs.launchpad.net/neutron/+bug/1956344 - "Functional test test_gateway_chassis_rebalance is failing intermittently" - Assigned to: Rodolfo Alonso
High:
* https://bugs.launchpad.net/neutron/+bug/1956034 - "ovn load balancer health monitor cause mac address conflict" - Unassigned
* https://bugs.launchpad.net/neutron/+bug/1956745 - " [ovn-octavia-provider] Load Balancer remained with ACTIVE state even with PENDING_UPDATE listener" - Assigned to: Luis Tomas Bolivar
* https://bugs.launchpad.net/neutron/+bug/1956763 - "[OVN] Overlapping configuration for security group logging is not applied correctly" - Assigned to: Elvira Garcia Ruiz
Medium:
* https://bugs.launchpad.net/neutron/+bug/1956035 - "ovn load balancer member failover not working when accessed from floating ip" - Unassigned
* https://bugs.launchpad.net/neutron/+bug/1956632 - "DNS integration documentation and scenario tests need update after dns_assignment calculation was changed" - Assigned to: Miguel Lavalle
* https://bugs.launchpad.net/neutron/+bug/1956785 - "Duplicate validator TypeError for dict values Edit" - Assigned to: Harald Jensås
Low:
* https://bugs.launchpad.net/neutron/+bug/1956476 - "[OVN] Disallow multiple physnets per bridge" - Assigned to: Rodolfo Alonso
* https://bugs.launchpad.net/neutron/+bug/1956770 - " keepalived no_track implemented in >= 2.0.3" - Assigned to: Rodolfo Alonso
Needs further triage:
* https://bugs.launchpad.net/neutron/+bug/1956435 - "OVS: support multiple segments per host" - Unassigned
* https://bugs.launchpad.net/neutron/+bug/1956460 - "The VM can't get metadata from dhcp-agent" - Unassigned
* https://bugs.launchpad.net/neutron/+bug/1956846 - "ha router duplicated routes" - Unassigned
Cheers, Lucas
Hello Lucas,
I hope you don't mind my rather blunt question, but how do tickets end up on this list? I read https://docs.openstack.org/neutron/latest/contributor/policies/bugs.html#neu... but am just wondering if there is anything else I should have done when reporting the issue?
I don't just want to shout louder and certainly everybody wants their issue to be looked at and fixed first. But I just noticed that my bug report received no reply or confirmation in the last three months (apart from the tag "vpnaas" being added), while other issues were triaged quickly and were consequently added to this deputy report ...
On 10/01/2022 22:17, Lucas Alvares Gomes wrote:
[...]
- https://bugs.launchpad.net/neutron/+bug/1956846 - "ha router
duplicated routes"
- Unassigned
[...]
Similar to those duplicate routes, I reported an issue about duplicated IPtables causing VPNaaS not not work in https://bugs.launchpad.net/neutron/+bug/1943449.
With kind regards,
Christian
Hi,
On środa, 12 stycznia 2022 16:03:47 CET Christian Rohmann wrote:
Hello Lucas,
I hope you don't mind my rather blunt question, but how do tickets end up on this list? I read https://docs.openstack.org/neutron/latest/contributor/policies/
bugs.html#neut
ron-bug-deputy but am just wondering if there is anything else I should have done when reporting the issue?
Bug deputy role in Neutron is rotated weekly. Usually person who is doing bug deputy is trying to do initial triage of the bug and then sends summary of such bugs to the ML. We also discuss some of the bugs during our weekly meeting [1]. There is nothing more on Your side which has to be done here.
I don't just want to shout louder and certainly everybody wants their issue to be looked at and fixed first. But I just noticed that my bug report received no reply or confirmation in the last three months (apart from the tag "vpnaas" being added), while other issues were triaged quickly and were consequently added to this deputy report ...
The problem with neutron-vpnaas is that there is almost no one who is maintining that project currently and probably because of that nobody works on the bug which You reported. If You are using that project and are interested in maintaining it, patches are always welcome :)
On 10/01/2022 22:17, Lucas Alvares Gomes wrote:
[...]
- https://bugs.launchpad.net/neutron/+bug/1956846 - "ha router
duplicated routes"
- Unassigned
[...]
Similar to those duplicate routes, I reported an issue about duplicated IPtables causing VPNaaS not not work in https://bugs.launchpad.net/neutron/+bug/1943449.
With kind regards,
Christian
[1] https://meetings.opendev.org/#Neutron_Team_Meeting
Hi Christian, Thanks for highlighting your issue with Linuxbridge driver and VPNaaS. I would like to ask you to consider the following, which will not give you an answer or solution to your problem but perhaps helps to understand and accept if any specific issue has not received the needed attention from the community. Basically it is the core team (and some enthusiasts around it) who do bug triaging in Neutron, they are experienced and willing to provide answers, solutions. The possible combinations of drivers, extensions, backends, deployment tools is huge, and there are combinations which are not well covered in the current community, like linuxbridge is not that used (OVS and perhaps OVN are the top tested and deployed, at least from latest user surveys). So it can happen that in the current core team nobody has the special knowledge and tools (test environment, hardware...) to debug a specific issue.
Neutron maintains a list of "lieutenants", to make easier to contact the right person: https://docs.openstack.org/neutron/latest/contributor/policies/neutron-teams... For VPNaaS the people are not active anymore in the community.
In such difficult to debug situation it is really helpful for the community if you can test the issue on current master code (it is possible that the issue happens only on older branches) and with tools that are available for most of us, like simple devstack.
Regards Lajos Katona (lajoskatona)
Christian Rohmann christian.rohmann@inovex.de ezt írta (időpont: 2022. jan. 12., Sze, 16:10):
Hello Lucas,
I hope you don't mind my rather blunt question, but how do tickets end up on this list? I read
https://docs.openstack.org/neutron/latest/contributor/policies/bugs.html#neu... but am just wondering if there is anything else I should have done when reporting the issue?
I don't just want to shout louder and certainly everybody wants their issue to be looked at and fixed first. But I just noticed that my bug report received no reply or confirmation in the last three months (apart from the tag "vpnaas" being added), while other issues were triaged quickly and were consequently added to this deputy report ...
On 10/01/2022 22:17, Lucas Alvares Gomes wrote:
[...]
- https://bugs.launchpad.net/neutron/+bug/1956846 - "ha router
duplicated routes"
- Unassigned
[...]
Similar to those duplicate routes, I reported an issue about duplicated IPtables causing VPNaaS not not work in https://bugs.launchpad.net/neutron/+bug/1943449.
With kind regards,
Christian
Hey Lajos, Slawek.
firstly I am truly very sorry about not responding to your kind message in any way until just now. I myself simply expected to be able to reproduce the issue quicker and postponed any response way too long. In any case: We were now able to reproduce the issue on DevStack with xena or master, see me comment at the end of this message.
On 13/01/2022 09:34, Lajos Katona wrote:
Thanks for highlighting your issue with Linuxbridge driver and VPNaaS. I would like to ask you to consider the following, which will not give you an answer or solution to your problem but perhaps helps to understand and accept if any specific issue has not received the needed attention from the community. Basically it is the core team (and some enthusiasts around it) who do bug triaging in Neutron, they are experienced and willing to provide answers, solutions. The possible combinations of drivers, extensions, backends, deployment tools is huge, and there are combinations which are not well covered in the current community, like linuxbridge is not that used (OVS and perhaps OVN are the top tested and deployed, at least from latest user surveys). So it can happen that in the current core team nobody has the special knowledge and tools (test environment, hardware...) to debug a specific issue.
I understand and thank you for your patience in explaining this (likely not for the first time). I am already tracking the progress happening in regards to OVN, but unfortunately support for VPNaaS is still not available there, but there is a pending change at https://review.opendev.org/c/openstack/neutron-vpnaas/+/765353.
On 13/01/2022 09:18, Slawek Kaplonski wrote:
I don't just want to shout louder and certainly everybody wants their issue to be looked at and fixed first. But I just noticed that my bug report received no reply or confirmation in the last three months (apart from the tag "vpnaas" being added), while other issues were triaged quickly and were consequently added to this deputy report ...
The problem with neutron-vpnaas is that there is almost no one who is maintining that project currently and probably because of that nobody works on the bug which You reported. If You are using that project and are interested in maintaining it, patches are always welcome:)
Not to push back on anything your said, it's just a bit frustrating sometimes that there seems to be no explicit deprecation and then EoL path for certain backends / drivers. To me this would be totally understandable as a way to free development time and bug hunting efforts. And at the same time this means providing some strong guidance to the userbase what to avoid or actively moving away from.
The most prominent example to me, as our deployment was affected by this as well, is using PostgreSQL as DBMS. While there is this message, https://governance.openstack.org/tc/resolutions/20170613-postgresql-status.h..., explaining that there will be less focus on PostgreSQL, it would actually be much better to simply deprecate support for this DBMS and then clearly state this for the next releases. With a state of "supported, but not widely used", users will just have a hard time getting their reported bugs validated and fixed. Even reviewers for sent in patches are hard to find, see e.g. https://review.opendev.org/c/openstack/designate/+/668493. But even if an issue was found and fixed, as https://review.opendev.org/c/openstack/glance/+/820247, a similar issue is just around the corner, as this configuration is just not actively tested and validated.
Looking at Neutron there are lots of tables and comparisons. But I am not convinced the feature tables and complex interdependencies at
* https://docs.openstack.org/neutron/latest/feature_classification/general_fea... * https://docs.openstack.org/neutron/latest/admin/config-ml2.html#id5 * https://docs.openstack.org/neutron/latest/ovn/gaps.html
help a new Neutron user to make the right choices. I already somewhat read between the lines that OVS support could be dropped in favor of OVN at some point - like RedHat recommends and explains here: https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16....
What I am trying to say is that it would be ok to drop support for something at some point to free time and effort to focus on more common configurations and making them work as best they can. But this also includes making active recommendations and getting the missing features tackled (as in VPNaaS for OVN) so people can actually be asked to migrate away from a EoL config.
On 13/01/2022 09:34, Lajos Katona wrote:
Neutron maintains a list of "lieutenants", to make easier to contact the right person: https://docs.openstack.org/neutron/latest/contributor/policies/neutron-teams... For VPNaaS the people are not active anymore in the community. In such difficult to debug situation it is really helpful for the community if you can test the issue on current master code (it is possible that the issue happens only on older branches) and with tools that are available for most of us, like simple devstack.
My colleague Niklas Schwarz did setup two devstack nodes and documented their config as well as required steps setting up VPNs to then trigger the reported duplicate iptables issue, see https://bugs.launchpad.net/neutron/+bug/1943449/comments/4. Please kindly take a look and let me know if there is any more details we need to provide. But since we have this issue reproducible in devstack I hope you'll be able to narrow it down.
Regards and thanks again for your patience,
Christian
Hi Christian, Thanks for your efforts for reproduction. I will bring this topic to the team meeting tomorrow ( https://meetings.opendev.org/#Neutron_Team_Meeting ): https://wiki.openstack.org/wiki/Network/Meetings#On_Demand_Agenda
Regarding your frustration, I totally understand it. It is, I think can be a topic for the coming PTG.
Regards Lajos Katona (lajoskatona)
Christian Rohmann christian.rohmann@inovex.de ezt írta (időpont: 2022. márc. 16., Sze, 23:23):
Hey Lajos, Slawek.
firstly I am truly very sorry about not responding to your kind message in any way until just now. I myself simply expected to be able to reproduce the issue quicker and postponed any response way too long. In any case: We were now able to reproduce the issue on DevStack with xena or master, see me comment at the end of this message.
On 13/01/2022 09:34, Lajos Katona wrote:
Thanks for highlighting your issue with Linuxbridge driver and VPNaaS. I would like to ask you to consider the following, which will not give you an answer or solution to your problem but perhaps helps to understand and accept if any specific issue has not received the needed attention from the community. Basically it is the core team (and some enthusiasts around it) who do bug triaging in Neutron, they are experienced and willing to provide answers, solutions. The possible combinations of drivers, extensions, backends, deployment tools is huge, and there are combinations which are not well covered in the current community, like linuxbridge is not that used (OVS and perhaps OVN are the top tested and deployed, at least from latest user surveys). So it can happen that in the current core team nobody has the special knowledge and tools (test environment, hardware...) to debug a specific issue.
I understand and thank you for your patience in explaining this (likely not for the first time). I am already tracking the progress happening in regards to OVN, but unfortunately support for VPNaaS is still not available there, but there is a pending change at https://review.opendev.org/c/openstack/neutron-vpnaas/+/765353.
On 13/01/2022 09:18, Slawek Kaplonski wrote:
I don't just want to shout louder and certainly everybody wants their issue to be looked at and fixed first. But I just noticed that my bug report received no reply or confirmation in the last three months (apart from the tag "vpnaas" being added), while other issues were triaged quickly and were consequently added to this deputy report ...
The problem with neutron-vpnaas is that there is almost no one who is maintining that project currently and probably because of that nobody works on the bug which You reported. If You are using that project and are interested in maintaining it, patches are always welcome :)
Not to push back on anything your said, it's just a bit frustrating sometimes that there seems to be no explicit deprecation and then EoL path for certain backends / drivers. To me this would be totally understandable as a way to free development time and bug hunting efforts. And at the same time this means providing some strong guidance to the userbase what to avoid or actively moving away from.
The most prominent example to me, as our deployment was affected by this as well, is using PostgreSQL as DBMS. While there is this message, https://governance.openstack.org/tc/resolutions/20170613-postgresql-status.h..., explaining that there will be less focus on PostgreSQL, it would actually be much better to simply deprecate support for this DBMS and then clearly state this for the next releases. With a state of "supported, but not widely used", users will just have a hard time getting their reported bugs validated and fixed. Even reviewers for sent in patches are hard to find, see e.g. https://review.opendev.org/c/openstack/designate/+/668493. But even if an issue was found and fixed, as https://review.opendev.org/c/openstack/glance/+/820247, a similar issue is just around the corner, as this configuration is just not actively tested and validated.
Looking at Neutron there are lots of tables and comparisons. But I am not convinced the feature tables and complex interdependencies at
https://docs.openstack.org/neutron/latest/feature_classification/general_fea...
- https://docs.openstack.org/neutron/latest/admin/config-ml2.html#id5
- https://docs.openstack.org/neutron/latest/ovn/gaps.html
help a new Neutron user to make the right choices. I already somewhat read between the lines that OVS support could be dropped in favor of OVN at some point - like RedHat recommends and explains here: https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16....
What I am trying to say is that it would be ok to drop support for something at some point to free time and effort to focus on more common configurations and making them work as best they can. But this also includes making active recommendations and getting the missing features tackled (as in VPNaaS for OVN) so people can actually be asked to migrate away from a EoL config.
On 13/01/2022 09:34, Lajos Katona wrote:
Neutron maintains a list of "lieutenants", to make easier to contact the right person:
https://docs.openstack.org/neutron/latest/contributor/policies/neutron-teams... For VPNaaS the people are not active anymore in the community. In such difficult to debug situation it is really helpful for the community if you can test the issue on current master code (it is possible that the issue happens only on older branches) and with tools that are available for most of us, like simple devstack.
My colleague Niklas Schwarz did setup two devstack nodes and documented their config as well as required steps setting up VPNs to then trigger the reported duplicate iptables issue, see https://bugs.launchpad.net/neutron/+bug/1943449/comments/4. Please kindly take a look and let me know if there is any more details we need to provide. But since we have this issue reproducible in devstack I hope you'll be able to narrow it down.
Regards and thanks again for your patience,
Christian
Hey Lajos,
On 21/03/2022 11:12, Lajos Katona wrote:
Hi Christian, Thanks for your efforts for reproduction. I will bring this topic to the team meeting tomorrow (https://meetings.opendev.org/#Neutron_Team_Meeting ): https://wiki.openstack.org/wiki/Network/Meetings#On_Demand_Agenda
Regarding your frustration, I totally understand it. It is, I think can be a topic for the coming PTG.
1) First thanks again for raising issue of a lack of maintainers for VPNaaS at https://meetings.opendev.org/meetings/networking/2022/networking.2022-03-22-... https://meetings.opendev.org/meetings/networking/2022/networking.2022-03-22-14.06.log.html#l-62. Were there any more take-aways from your PTG discussion if I may ask?
Is there any chance anybody might look at our reported and DevStack-reproduced issue about the duplicate IPtable rules (https://bugs.launchpad.net/neutron/+bug/1943449) ? Do you need more info of any kind?
2) If there is a way forward for keeping VPNaaS ...
* Will OVN receive support at some point? https://review.opendev.org/c/openstack/neutron-vpnaas/+/765353 https://review.opendev.org/c/openstack/neutron-vpnaas/+/765353
3) More protocols?
Are there any plans on extending on the types as currently only IPSEC is supported (https://opendev.org/openstack/neutron-vpnaas/src/branch/master/neutron_vpnaa...). I was thinking about Wireguard which is also built into the linux kernel and saw amazing pick-up in recent times. Even consumer devices use it now as it's MUCH simpler than IPSEC.
Regards
Christian
Hi, We touched this topic during the PTG, but it seems that there was nobody from the participants who would like to maintain neutron-vpnaas, so I sent out a mail asking for help: http://lists.openstack.org/pipermail/openstack-discuss/2022-April/028123.htm...
Regards Lajos Katona (lajoskatona)
Christian Rohmann christian.rohmann@inovex.de ezt írta (időpont: 2022. ápr. 11., H, 11:00):
Hey Lajos,
On 21/03/2022 11:12, Lajos Katona wrote:
Hi Christian, Thanks for your efforts for reproduction. I will bring this topic to the team meeting tomorrow ( https://meetings.opendev.org/#Neutron_Team_Meeting ): https://wiki.openstack.org/wiki/Network/Meetings#On_Demand_Agenda
Regarding your frustration, I totally understand it. It is, I think can be a topic for the coming PTG.
- First thanks again for raising issue of a lack of maintainers for
VPNaaS at https://meetings.opendev.org/meetings/networking/2022/networking.2022-03-22-... . Were there any more take-aways from your PTG discussion if I may ask?
Is there any chance anybody might look at our reported and DevStack-reproduced issue about the duplicate IPtable rules ( https://bugs.launchpad.net/neutron/+bug/1943449) ? Do you need more info of any kind?
- If there is a way forward for keeping VPNaaS ...
- Will OVN receive support at some point?
https://review.opendev.org/c/openstack/neutron-vpnaas/+/765353
- More protocols?
Are there any plans on extending on the types as currently only IPSEC is supported ( https://opendev.org/openstack/neutron-vpnaas/src/branch/master/neutron_vpnaa... ). I was thinking about Wireguard which is also built into the linux kernel and saw amazing pick-up in recent times. Even consumer devices use it now as it's MUCH simpler than IPSEC.
Regards
Christian
participants (4)
-
Christian Rohmann
-
Lajos Katona
-
Lucas Alvares Gomes
-
Slawek Kaplonski