James Peach

You can approximate this with the `ingress.class` annotation to force Contour to ignore certain objects, but that's hacky and burdensome for operators.

Duplicate of #1241

This is something I've been thinking about for a while. We allow (or at least have no way to prevent) users to bring their own envoy, but we don't know...

@SDBrett envoy makes the version available in each [DiscoveryRequest](https://github.com/envoyproxy/envoy/blob/109d23a6648b1ac7723c4b2f125e913125bb9a84/api/envoy/api/v2/discovery.proto#L131) in the [Node message](https://github.com/envoyproxy/envoy/blob/109d23a6648b1ac7723c4b2f125e913125bb9a84/api/envoy/api/v2/core/base.proto#L48). It should be straight-forward for Contour to track the supported Envoy versions and at least log when...

> On 6 Dec 2019, at 10:51 am, Dave Cheney wrote: > > @SDBrett envoy makes the version available in each DiscoveryRequest in the Node message. > > hotdamn! when...

See envoyproxy/envoy#8332

Related to #1178

I generated cluster churn by concurrently adding and deleting HTTPProxy objects. While this was happening, I sent traffic to a different service in the same cluster that I wasn't modifying....

Tested a new scenario. This theory is that when a new envoy pod starts up, it will start taking requests before it has been fully programmed by Contour. If this...

So if there are changes when Contour isn't running, then you can get user-visible errors. However, when Contour starts coming up, those errors could transiently changes (e.g. 404 --> 503...