Open Stack

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.html, 
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_feature_support_matrix.html
  * 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.1/html/networking_with_open_virtual_network/migrating-ml2ovs-to-ovn

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.html#neutron-lieutenants
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220316/14e2a49d/attachment.htm>