Remove dependency on configbump

[nickboldt]

Is your task related to a problem? Please describe.

Mario suggested on a call today that the use of configbump was a temporary solution, and we shouldn't need to use it to tweak traefik.

Describe the solution you'd like

Remove configbump usage in Che 7.20.x and 7.21, and remove reference to it from CSV's RELATED_IMAGE list, so we have no dependency on it when building project or downstream product.

Describe alternatives you've considered

Build a new UBI-based image in Brew, productize it, and then throw it away in future when we don't depend on it anymore.

Additional context

Downstream issue: https://issues.redhat.com/browse/CRW-1260

[sparkoo]

AFAIK we've never said this is just temporary. We need configbump to bring the dynamic configuration into traefik container as fast as possible. I understand we want to get rid of it, as it is another component we need to maintain/build/deploy/... but so far I haven't seen actual technical proposal how to do it without significant performance impact.

[metlos]

We've done extensive testing on quite a number of solutions including several ways of configuring Traefik and the approach using configbump came out as a winner. Configbump does not tweak Traefik in any way, it merely provides configuration to it in a way that is fully supported by Traefik.

[nickboldt]

I'm just relaying what I was told based on the questions asked in CRW-1260 and how best to work around them in the product space. If I've misrepresented the solution as a "hack" my apologies -- I just want to understand what it does, why it's needed, and if there's a simpler way to get to 'happy' without adding Yet Another Container (or two, if we need to also productize Traefik itself) to the CRW 2.x pile.

Has anyone used https://catalog.redhat.com/software/containers/containous/traefikee/5e3d7f62ecb5246c09e2bdbf?container-tabs=overview ? is that as good as the pure upstream version?

[nickboldt]

Also dumb question, but are you on traefik 2.2.8 for a specific reason? Would it make sense to move to the latest 2.3.1 for the upcoming Che 7.20 release?

[sparkoo]

Also dumb question, but are you on traefik 2.2.8 for a specific reason? Would it make sense to move to the latest 2.3.1 for the upcoming Che 7.20 release?

Only reason is that it was the latest when we pushed it into Che. We can test the 2.3.1 and update if ok.

[l0rd]

We had a call this morning. @metlos and @sparkoo did investigate after we spoke last time and unfortunately both Traefik providers on Kubernetes (Ingress and IngressRoute) are slower than configbump + File provider AND require more privileges at deploying time.

Hence, even if it would have been better not to maintain something that looks like a Traefik extension (a ConfigMap based provider), we currently don't have a better choice. In the meantime @metlos and @sparkoo will investigate if there is an interest on a CM based Traefik provider with the Traefik community.

@nickboldt from my point of view this issue can be closed

[nickboldt]

OK, understood.

Can we use https://catalog.redhat.com/software/containers/containous/traefikee/5e3d7f62ecb5246c09e2bdbf?container-tabs=overview in CRW (and maybe in Che too?) instead of building traefik from upstream 2.3.1 tag and publishing our own container?

[l0rd]

OK, understood.

Can we use catalog.redhat.com/software/containers/containous/traefikee/5e3d7f62ecb5246c09e2bdbf?container-tabs=overview in CRW (and maybe in Che too?) instead of building traefik from upstream 2.3.1 tag and publishing our own container?

Who is maintaining that image? Because it's a 6 months old image and latest on dockerhub is from 2 days ago.
Anyway traefikee is different from traefik. And using it upstream looks impractible.

[metlos]

In the meantime @metlos and @sparkoo will investigate if there is an interest on a CM based Traefik provider with the Traefik community.

I wrote a forum post to ask if there was interest in this:
https://community.traefik.io/t/traefik-as-a-reverse-proxy-inside-a-kubernetes-namespace/8093