cloudfoundry / diego-release

BOSH Release for Diego

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Use supported envoy version >1.19.1

plowin opened this issue · comments

Use supported envoy version >1.19.1

Summary

Hi,
in diego-release an unsupported version of envoy is used (1.19.1). It was last updated in Sep 2021 with this PR.

1.19 was archived in June 2022 and supported versions are 1.20 - 1.23 at the current point in time.

In another issue, it was targeted to enable auto-bumps, but the issue was closed.

Steps to Reproduce

cf ssh into an app container and find the envoy version with

$ /etc/cf-assets/envoy/envoy --version
/etc/cf-assets/envoy/envoy  version: a2a1e3eed4214a38608ec223859fcfa8fb679b14/1.19.1/Clean/RELEASE/BoringSSL

Diego repo

Directly in diego-release, files referenced here:
https://github.com/cloudfoundry/diego-release/pull/590/files

Environment Details

This is for all recent cf-deployments or diego-releases.

Possible Causes or Fixes (optional)

  1. Bump to a supported version
  2. Enable auto-bumping

Thanks for bringing this up @plowin.

We have an "update-envoy-blob" job in our pipeline that should run every time it gets a new image. But it looks like it hasn't gotten a new image since dec 2021. I will add a bug to our backlog to investigate.

Thanks!
You are referring to some internal pipelines outside the ones around networking on the WG-concourse? At least, I could not find the job there

Yes, it is a pipeline that the Diego approvers have access to. This work is currently prioritized.

Hi @ameowlia, do you know if the item was picked yet?

Hi @plowin, we merged a bump yesterday! https://github.com/cloudfoundry/diego-release/pull/682/files

And even better, the automatic bump pipeline is working again.

Thanks for raising this issue!

hey @plowin! We had to revert the bump above as it was incompatible with cflinuxfs3. The envoy binary we pull in isn't statically compiled against OS libraries and had libc issues. Fortunately 1.23.x still works, so we bumped back up to that version after the revert.

For the long term, we're looking at statically compiling the binary ourselves, or otherwise solving the cross-stack libc issue.