<div dir="ltr">Hi Christian,<div>Thanks for your efforts for reproduction.</div><div>I will bring this topic to the team meeting tomorrow (<a href="https://meetings.opendev.org/#Neutron_Team_Meeting">https://meetings.opendev.org/#Neutron_Team_Meeting</a> ):</div><div><a href="https://wiki.openstack.org/wiki/Network/Meetings#On_Demand_Agenda">https://wiki.openstack.org/wiki/Network/Meetings#On_Demand_Agenda</a><br></div><div><br></div><div>Regarding your frustration, I totally understand it. It is, I think can be a topic for the coming PTG.</div><div><br></div><div>Regards</div><div>Lajos Katona (lajoskatona)</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Christian Rohmann <<a href="mailto:christian.rohmann@inovex.de">christian.rohmann@inovex.de</a>> ezt írta (időpont: 2022. márc. 16., Sze, 23:23):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>
    <div>Hey Lajos, Slawek.<br>
    </div>
    <div><br>
    </div>
    <div>firstly I am truly very sorry about not
      responding to your kind message in any way until just now.<br>
      I myself simply expected to be able to reproduce the issue quicker
      and postponed any response way too long.<br>
      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.<br>
      <br>
    </div>
    <div><br>
    </div>
    <div>On 13/01/2022 09:34, Lajos Katona
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">Thanks for highlighting your issue with Linuxbridge
        driver and VPNaaS.
        <div>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.</div>
        <div>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.</div>
        <div>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.</div>
      </div>
    </blockquote>
    <p>I understand and thank you for your patience in explaining this
      (likely not for the first time).<br>
      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
      <a href="https://review.opendev.org/c/openstack/neutron-vpnaas/+/765353" target="_blank">https://review.opendev.org/c/openstack/neutron-vpnaas/+/765353</a>.</p>
    <p><br>
    </p>
    <div>On 13/01/2022 09:18, Slawek Kaplonski
      wrote:<br>
    </div>
    <blockquote type="cite">
      <blockquote type="cite" style="color:rgb(0,124,255)">
        <pre>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 ...
</pre>
      </blockquote>
      <pre>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 <span title=":)"><span>:)</span></span>
</pre>
    </blockquote>
    <p>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.<br>
      And at the same time this means providing some strong guidance to
      the userbase what to avoid or actively moving away from.<br>
    </p>
    <p>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,
<a href="https://governance.openstack.org/tc/resolutions/20170613-postgresql-status.html" target="_blank">https://governance.openstack.org/tc/resolutions/20170613-postgresql-status.html</a>,
      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. <br>
      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.
      <a href="https://review.opendev.org/c/openstack/designate/+/668493" target="_blank">https://review.opendev.org/c/openstack/designate/+/668493</a>. But
      even if an issue was found and fixed, as
      <a href="https://review.opendev.org/c/openstack/glance/+/820247" target="_blank">https://review.opendev.org/c/openstack/glance/+/820247</a>, a similar
      issue is just around the corner, as this configuration is just not
      actively tested and validated.<br>
    </p>
    <p>Looking at Neutron there are lots of tables and comparisons. But
      I am not convinced the feature tables and complex
      interdependencies at <br>
    </p>
    <p> *
<a href="https://docs.openstack.org/neutron/latest/feature_classification/general_feature_support_matrix.html" target="_blank">https://docs.openstack.org/neutron/latest/feature_classification/general_feature_support_matrix.html</a><br>
       *
      <a href="https://docs.openstack.org/neutron/latest/admin/config-ml2.html#id5" target="_blank">https://docs.openstack.org/neutron/latest/admin/config-ml2.html#id5</a><br>
       * <a href="https://docs.openstack.org/neutron/latest/ovn/gaps.html" target="_blank">https://docs.openstack.org/neutron/latest/ovn/gaps.html</a></p>
    <p>help a new Neutron user to make the right choices.<br>
      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:
<a href="https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.1/html/networking_with_open_virtual_network/migrating-ml2ovs-to-ovn" target="_blank">https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.1/html/networking_with_open_virtual_network/migrating-ml2ovs-to-ovn</a><br>
      <br>
      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.<br>
      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.<br>
    </p>
    <p><br>
    </p>
    <p>On 13/01/2022 09:34, Lajos Katona wrote:</p>
    <blockquote type="cite">
      <div dir="ltr">
        <div><br>
        </div>
        <div>Neutron maintains a list of "lieutenants", to make easier
          to contact the right person:</div>
        <div><a href="https://docs.openstack.org/neutron/latest/contributor/policies/neutron-teams.html#neutron-lieutenants" target="_blank">https://docs.openstack.org/neutron/latest/contributor/policies/neutron-teams.html#neutron-lieutenants</a><br>
        </div>
        <div>For VPNaaS the people are not active anymore in the
          community.<br>
        </div>
        <div>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.</div>
      </div>
    </blockquote>
    <p>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
      <a href="https://bugs.launchpad.net/neutron/+bug/1943449/comments/4" target="_blank">https://bugs.launchpad.net/neutron/+bug/1943449/comments/4</a>.<br>
      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.</p>
    <p><br>
    </p>
    <p><br>
    </p>
    <p><br>
    </p>
    <p>Regards and thanks again for your patience,<br>
      <br>
      <br>
      Christian<br>
    </p>
    <br>
  </div>

</blockquote></div>