internal/contour: decouple the cache handler #2753
Conversation
|
@stevesloka This PR came out of trying to see how we can better integrate EDS with knowledge of the DAG. It heavily conflicts with your go-control-plane refactor, so we probably want to see whether it still makes sense in conjunction with that. |
Codecov Report
@@ Coverage Diff @@
## master #2753 +/- ##
==========================================
- Coverage 76.79% 76.67% -0.13%
==========================================
Files 72 72
Lines 5775 5792 +17
==========================================
+ Hits 4435 4441 +6
- Misses 1252 1259 +7
- Partials 88 92 +4
|
Alternatively, it might make the go-control-plane change easier 🤷 |
|
I ripped out the entire cachehandler in #2604. |
c2c94f5 to
13c9454
Compare
🥳 I was able to remove it from this PR too. It's replaced by composing DAG observers. |
skriss
left a comment
There was a problem hiding this comment.
Looks pretty good to me, just a handful of minor comments and a question.
13c9454 to
04ea6e0
Compare
|
@skriss @youngnick This is ready for the next review pass. Thanks :) |
04ea6e0 to
69159da
Compare
youngnick
left a comment
There was a problem hiding this comment.
LGTM. I don't think we've used interface assertions much before. It feels a little bit of a weird syntax for me, but I can see that it's useful. If we're going to add them, we should either do it for everything or not do it though, I think.
69159da to
3e3ae0d
Compare
I removed these. |
The `contour.CacheHandler` struct contains the xDS resource caches as embedded members. If we extract a DAG observer interface, however, we can remove knowledge of specific resources from `CacheHandler`. All it really needs is a set of objects that can vist the DAG when it changes to generate any relevant xDS resources, and that can be called on to publish those into the xDS GRPC interface. Separating out the new `contour.ResourceCache` interface gives us the opportunity to add new DAG consumers by only having to modify code when the Contour server starts up. There's no longer any cache handler plumbing needed. Once we can compose the xDS caches under the `Observer` interface, the need for a separate cache handler struct goes away, and we can attach everything we need directly to the event handler. This updates projectcontour#2775. Signed-off-by: James Peach <[email protected]>
3e3ae0d to
ff326b2
Compare
The
contour.CacheHandlerstruct contains the xDS resource caches asembedded members. If we extract a DAG observer interface, however, we
can remove knowledge of specific resources from
CacheHandler.All it really needs is a set of objects that can vist the DAG when it
changes to generate any relevant xDS resources, and that can be called
on to publish those into the xDS GRPC interface.
Separating out the new
contour.ResourceCacheinterface gives us theopportunity to add new DAG consumers by only having to modify code
when the Contour server starts up. There's no longer any cache handler
plumbing needed.
Once we can compose the xDS caches under the
Observerinterface, theneed for a separate cache handler struct goes away, and we can attach
everything we need directly to the event handler.
This updates #2775.