Introduce DAG model consumer abstractions #2775
Assignees
Labels
kind/cleanup
Categorizes issue or PR as related to cleaning up code, process, or technical debt.
Comments
jpeach
added
the
kind/cleanup
jpeach
added a commit
to jpeach/contour
that referenced
this issue
Aug 7, 2020
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 <jpeach@vmware.com>
jpeach
added a commit
to jpeach/contour
that referenced
this issue
Aug 9, 2020
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 <jpeach@vmware.com>
jpeach
added a commit
to jpeach/contour
that referenced
this issue
Aug 10, 2020
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 <jpeach@vmware.com>
jpeach
added a commit
to jpeach/contour
that referenced
this issue
Aug 10, 2020
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 <jpeach@vmware.com>
jpeach
added a commit
to jpeach/contour
that referenced
this issue
Aug 10, 2020
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 <jpeach@vmware.com>
jpeach
added a commit
that referenced
this issue
Aug 10, 2020
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 #2775. Signed-off-by: James Peach <jpeach@vmware.com>
jpeach
added a commit
to jpeach/contour
that referenced
this issue
Aug 11, 2020
* Switch from shutting down gRPC server with `Stop()` to `GracefulStop()`. which waits for current requests to drain before returning. This means that tests which log to the test runner won't ever attempt to log after the test has completed. * Hoist test loggers into the fixtures package and use them from there. * Add a workgroup context cancellation test. This updates projectcontour#2775. Signed-off-by: James Peach <jpeach@vmware.com>
jpeach
added a commit
that referenced
this issue
Aug 11, 2020
* Switch from shutting down gRPC server with `Stop()` to `GracefulStop()`. which waits for current requests to drain before returning. This means that tests which log to the test runner won't ever attempt to log after the test has completed. * Hoist test loggers into the fixtures package and use them from there. * Add a workgroup context cancellation test. This updates #2775. Signed-off-by: James Peach <jpeach@vmware.com>
jpeach
added a commit
to jpeach/contour
that referenced
this issue
Aug 11, 2020
Add a `xds` package that exports a basic interface that xDS servers can implement. Move the existing Contour xDS server into this package, and add a factory function to create an instance of it. After this change, different xDS server implementations can be selected at startup. This fixes projectcontour#2775. Signed-off-by: James Peach <jpeach@vmware.com>
jpeach
added a commit
to jpeach/contour
that referenced
this issue
Aug 11, 2020
Add a `xds` package that exports a basic interface that xDS servers can implement. Move the existing Contour xDS server into this package, and add a factory function to create an instance of it. After this change, different xDS server implementations can be selected at startup. This fixes projectcontour#2775. Signed-off-by: James Peach <jpeach@vmware.com>
jpeach
added a commit
to jpeach/contour
that referenced
this issue
Aug 11, 2020
Add a `xds` package that exports a basic interface that xDS servers can implement. Move the existing Contour xDS server into this package, and add a factory function to create an instance of it. After this change, different xDS server implementations can be selected at startup. This fixes projectcontour#2775. Signed-off-by: James Peach <jpeach@vmware.com>
jpeach
added a commit
to jpeach/contour
that referenced
this issue
Aug 11, 2020
Add a `xds` package that exports a basic interface that xDS servers can implement. Move the existing Contour xDS server into this package, and add a factory function to create an instance of it. After this change, different xDS server implementations can be selected at startup. This fixes projectcontour#2775. Signed-off-by: James Peach <jpeach@vmware.com>
jpeach
added a commit
to jpeach/contour
that referenced
this issue
Aug 12, 2020
Add a `xds` package that exports a basic interface that xDS servers can implement. Move the existing Contour xDS server into this package, and add a factory function to create an instance of it. After this change, different xDS server implementations can be selected at startup. This fixes projectcontour#2775. Signed-off-by: James Peach <jpeach@vmware.com>
jpeach
added a commit
to jpeach/contour
that referenced
this issue
Aug 12, 2020
Add a `xds` package that exports a basic interface that xDS servers can implement. Move the existing Contour xDS server into this package, and add a factory function to create an instance of it. After this change, different xDS server implementations can be selected at startup. This fixes projectcontour#2775. Signed-off-by: James Peach <jpeach@vmware.com>
jpeach
added a commit
that referenced
this issue
Aug 12, 2020
Add a `xds` package that exports a basic interface that xDS servers can implement. Move the existing Contour xDS server into this package, and add a factory function to create an instance of it. After this change, different xDS server implementations can be selected at startup. This fixes #2775. Signed-off-by: James Peach <jpeach@vmware.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Please describe the problem you have
We have a few different features coming up that affect the way we consume resources that Contour models in the DAG:
Most of these features will need to be enabled or disables in configuration. This issue addresses creating the right internal abstractions for adding the features above without creating a ton of churn through Contour internals.
The text was updated successfully, but these errors were encountered: