Open Stack

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 at 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.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/20220321/64fe752f/attachment.htm>