<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 16, 2021 at 1:20 AM Dan Sneddon <<a href="mailto:dsneddon@redhat.com">dsneddon@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I have been in pre-deployment discussions with a couple of operators <br>
over the last 18 months or so when it came up. I think the intent was to <br>
use IPSEC hardware offload using the NIC, but I don't know if they ended <br>
up using TLS in production once they learned that TLS was a vastly more <br>
common option.<br>
<br>
I think at the very least the presence of the IPSEC code and the fact <br>
that it's being maintained gives the impression that it is a valid <br>
option. There may be environments where IPSEC is used outside the <br>
OpenStack deployment, and a desire for consistency. There may even be <br>
some operators that would want to use both for the added layers of <br>
defense, possibly using IPSEC offload to offset the performance impact.<br>
<br>
I wouldn't be against deprecating it, but I think that the IPSEC code <br>
still has some mind-share.<br></blockquote><div><br></div><div><br></div><div>Thanks for the input Dan - more comments in response to Alex below:</div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-Dan<br>
<br>
On 2/15/21 6:39 AM, Alex Schultz wrote:<br>
> Is this thing still even used?  I thought it was a temporary thing until <br>
> TLS everywhere was finished. If it's not used we should just retire it.<br>
</blockquote><div><br></div><div><br></div><div>o/ good question. The repo hasn't had any action in over a year (ignoring top two commits to tox.ini).<br><br>We do carry a tripleo-heat-templates file for it @ [1] and environment [2] so there may well be folks using it. However as noted by Dan we really *should* deprecate it if no-one is maintaining this code. <br><br>Right now we need to move to independent, both to unblock the release jobs, but also so that we as tripleo are no longer required to create a stable branch for this repo. We can still tag a version if that is needed by someone, but no longer tied to a particular release/branch.<br><br>Moving forward we can start a conversation around deprecating and ultimately removing it in the next cycle, assuming there are no objections to that (i.e. folks using that). <br><br>regards, marios<br><br>[1] <a href="https://opendev.org/openstack/tripleo-heat-templates/src/commit/8d612ea015c0fc60b0756c5d395aa4a1653e6130/deployment/ipsec/ipsec-baremetal-ansible.yaml">https://opendev.org/openstack/tripleo-heat-templates/src/commit/8d612ea015c0fc60b0756c5d395aa4a1653e6130/deployment/ipsec/ipsec-baremetal-ansible.yaml</a><br>[2] <a href="https://opendev.org/openstack/tripleo-heat-templates/src/commit/8d612ea015c0fc60b0756c5d395aa4a1653e6130/environments/ipsec.yaml">https://opendev.org/openstack/tripleo-heat-templates/src/commit/8d612ea015c0fc60b0756c5d395aa4a1653e6130/environments/ipsec.yaml</a><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> <br>
> On Fri, Feb 12, 2021 at 7:35 AM Marios Andreou <<a href="mailto:marios@redhat.com" target="_blank">marios@redhat.com</a> <br>
> <mailto:<a href="mailto:marios@redhat.com" target="_blank">marios@redhat.com</a>>> wrote:<br>
> <br>
>     hello TripleO,<br>
> <br>
>     per $subject I want to propose that tripleo-ipsec moves to the<br>
>     independent release model, as done recently for os-collect-config<br>
>     and friends at [1].<br>
> <br>
>     The tripleo-ipsec repo hasn't had much/any commits in the last year<br>
>     [2]. In fact, we hadn't even created a ussuri branch for this repo<br>
>     and no-one noticed (!).<br>
> <br>
>     Because of the lack of stable/ussuri some of the release jobs<br>
>     failed, as discussed at [3] and which ttx tried to fix (thank you!)<br>
>     with [4].<br>
> <br>
>     Unfortunately this hasn't resolved the issue and jobs are still<br>
>     failing, as discussed just now in openstack-release [4]. If we agree<br>
>     to move tripleo-ipsec to independent then it will also resolve this<br>
>     build job issue.<br>
> <br>
>     If we move tripleo-ipsec to independent it means we can still<br>
>     release it if required, but we will no longer create stable/branches<br>
>     for the repo.<br>
> <br>
>     please voice any objections here or go and comment on the proposal<br>
>     at [6]<br>
> <br>
>     thanks for reading!<br>
> <br>
>     regards, marios<br>
> <br>
> <br>
>     [1] <a href="https://review.opendev.org/c/openstack/releases/+/772570" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/releases/+/772570</a><br>
>     <<a href="https://review.opendev.org/c/openstack/releases/+/772570" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/releases/+/772570</a>><br>
>     [2]<br>
>     <a href="https://opendev.org/openstack/tripleo-ipsec/commits/branch/master" rel="noreferrer" target="_blank">https://opendev.org/openstack/tripleo-ipsec/commits/branch/master</a><br>
>     <<a href="https://opendev.org/openstack/tripleo-ipsec/commits/branch/master" rel="noreferrer" target="_blank">https://opendev.org/openstack/tripleo-ipsec/commits/branch/master</a>><br>
>     [3]<br>
>     <a href="http://lists.openstack.org/pipermail/openstack-discuss/2021-January/020112.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-discuss/2021-January/020112.html</a><br>
>     <<a href="http://lists.openstack.org/pipermail/openstack-discuss/2021-January/020112.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-discuss/2021-January/020112.html</a>><br>
>     [4] <a href="https://review.opendev.org/c/openstack/releases/+/772995" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/releases/+/772995</a><br>
>     <<a href="https://review.opendev.org/c/openstack/releases/+/772995" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/releases/+/772995</a>><br>
>     [5]<br>
>     <a href="http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-release.2021-02-12.log.html" rel="noreferrer" target="_blank">http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-release.2021-02-12.log.html</a><br>
>     <<a href="http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-release.2021-02-12.log.html" rel="noreferrer" target="_blank">http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-release.2021-02-12.log.html</a>><br>
>     [6] <a href="https://review.opendev.org/c/openstack/releases/+/775395" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/releases/+/775395</a><br>
>     <<a href="https://review.opendev.org/c/openstack/releases/+/775395" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/releases/+/775395</a>><br>
> <br>
<br>
</blockquote></div></div>