[tripleo] moving tripleo-ipsec to independent release model

Marios Andreou marios at redhat.com
Tue Feb 16 09:05:33 UTC 2021


On Tue, Feb 16, 2021 at 1:20 AM Dan Sneddon <dsneddon at redhat.com> wrote:

> I have been in pre-deployment discussions with a couple of operators
> over the last 18 months or so when it came up. I think the intent was to
> use IPSEC hardware offload using the NIC, but I don't know if they ended
> up using TLS in production once they learned that TLS was a vastly more
> common option.
>
> I think at the very least the presence of the IPSEC code and the fact
> that it's being maintained gives the impression that it is a valid
> option. There may be environments where IPSEC is used outside the
> OpenStack deployment, and a desire for consistency. There may even be
> some operators that would want to use both for the added layers of
> defense, possibly using IPSEC offload to offset the performance impact.
>
> I wouldn't be against deprecating it, but I think that the IPSEC code
> still has some mind-share.
>


Thanks for the input Dan - more comments in response to Alex below:



> -Dan
>
> On 2/15/21 6:39 AM, Alex Schultz wrote:
> > Is this thing still even used?  I thought it was a temporary thing until
> > TLS everywhere was finished. If it's not used we should just retire it.
>


o/ good question. The repo hasn't had any action in over a year (ignoring
top two commits to tox.ini).

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.

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.

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).

regards, marios

[1]
https://opendev.org/openstack/tripleo-heat-templates/src/commit/8d612ea015c0fc60b0756c5d395aa4a1653e6130/deployment/ipsec/ipsec-baremetal-ansible.yaml
[2]
https://opendev.org/openstack/tripleo-heat-templates/src/commit/8d612ea015c0fc60b0756c5d395aa4a1653e6130/environments/ipsec.yaml




> >
> > On Fri, Feb 12, 2021 at 7:35 AM Marios Andreou <marios at redhat.com
> > <mailto:marios at redhat.com>> wrote:
> >
> >     hello TripleO,
> >
> >     per $subject I want to propose that tripleo-ipsec moves to the
> >     independent release model, as done recently for os-collect-config
> >     and friends at [1].
> >
> >     The tripleo-ipsec repo hasn't had much/any commits in the last year
> >     [2]. In fact, we hadn't even created a ussuri branch for this repo
> >     and no-one noticed (!).
> >
> >     Because of the lack of stable/ussuri some of the release jobs
> >     failed, as discussed at [3] and which ttx tried to fix (thank you!)
> >     with [4].
> >
> >     Unfortunately this hasn't resolved the issue and jobs are still
> >     failing, as discussed just now in openstack-release [4]. If we agree
> >     to move tripleo-ipsec to independent then it will also resolve this
> >     build job issue.
> >
> >     If we move tripleo-ipsec to independent it means we can still
> >     release it if required, but we will no longer create stable/branches
> >     for the repo.
> >
> >     please voice any objections here or go and comment on the proposal
> >     at [6]
> >
> >     thanks for reading!
> >
> >     regards, marios
> >
> >
> >     [1] https://review.opendev.org/c/openstack/releases/+/772570
> >     <https://review.opendev.org/c/openstack/releases/+/772570>
> >     [2]
> >     https://opendev.org/openstack/tripleo-ipsec/commits/branch/master
> >     <https://opendev.org/openstack/tripleo-ipsec/commits/branch/master>
> >     [3]
> >
> http://lists.openstack.org/pipermail/openstack-discuss/2021-January/020112.html
> >     <
> http://lists.openstack.org/pipermail/openstack-discuss/2021-January/020112.html
> >
> >     [4] https://review.opendev.org/c/openstack/releases/+/772995
> >     <https://review.opendev.org/c/openstack/releases/+/772995>
> >     [5]
> >
> http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-release.2021-02-12.log.html
> >     <
> http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-release.2021-02-12.log.html
> >
> >     [6] https://review.opendev.org/c/openstack/releases/+/775395
> >     <https://review.opendev.org/c/openstack/releases/+/775395>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210216/a5f3665e/attachment-0001.html>


More information about the openstack-discuss mailing list