internal/dag: extract DAG processors from the main builder #2847

skriss · 2020-08-28T17:24:50Z

Extracts the logic specific to processing HTTPProxy, Ingress
APIs into their own processors that are invoked by the DAG
builder. Also extracts a listener processor to add HTTP/HTTPS
listeners after the other processors have run.

Signed-off-by: Steve Kriss [email protected]

updates #2226

Heavily inspired by all the work @stevesloka has done to date, and previous conversations between the maintainers.

I think there's still some more refactoring that can be done here, so this isn't necessarily final state, but it does hit the goal of being able to separate out processors for different APIs into their own types and turn them on/off at runtime, and I don't want this PR to get too large.

A few areas I have in mind for followup:

clean up the interfaces between the Builder, the Processors, the KubernetesCache. Specifically, I'd like the Processors not to depend on a full Builder, but a subset of it - something like a BuildContext (or we could move to using the DAG here). Also, it'd be nice for the Processors to have a read-only view on the KubernetesCache.
look at possibly moving the Processors into their own package(s)
decide if we want to have Processors operate directly on a DAG rather than using a Builder/BuildContext

jpeach

I think that this is a useful step towards breaking down the monolith. The main improvement I'd like is to remove the SetBuilder method.

Also, it'd be nice for the Processors to have a read-only view on the KubernetesCache.

Agreed; This is closely related to #2683, where I'd like to be able to shuffle the controller-runtime cache as the Source.

look at possibly moving the Processors into their own package(s)

I'd support this so that we can enforce clean interface usage.

decide if we want to have Processors operate directly on a DAG rather than using a Builder/BuildContext

I'm pretty sure it's possible to just have processors make passes over the DAG and not have a separate build context. That would be my preferred solution.

internal/dag/builder.go

skriss · 2020-08-31T15:20:18Z

I'm pretty sure it's possible to just have processors make passes over the DAG and not have a separate build context. That would be my preferred solution.

Would you move the services, virtualhosts, securevirtualhosts maps that are currently in the Builder into the DAG struct along with the related methods that enable the Processors to easily check for/record existence of those objects? Or did you have a different approach in mind for how the Processors would interact with the DAG?

I think there are some nice things about keeping the Builder/BuildContext and the final DAG separate - you can have a different API for builders of the DAG vs. consumers of the DAG, and also you know that a DAG object is always a "final" representation rather than in the process of being built.

stevesloka

/lgtm

jpeach

Looks great; a few optional suggestions.

jpeach · 2020-09-01T00:54:47Z

internal/dag/listener_processor.go

+// if there are virtual hosts and secure virtual hosts already
+// defined in the builder.
+func (p *ListenerProcessor) Run(builder *Builder) {
+	p.builder = builder


to be safe, add

defer func() {p.builder = nil}()

jpeach · 2020-09-01T00:55:36Z

internal/dag/ingress_processor.go

+// Run translates Ingresses into DAG objects and
+// adds them to the DAG builder.
+func (p *IngressProcessor) Run(builder *Builder) {
+	p.builder = builder


To be safe, add:

defer func() {p.builder = nil}()

jpeach · 2020-09-01T01:01:24Z

internal/dag/httpproxy_processor.go

+// adds them to the DAG builder.
+func (p *HTTPProxyProcessor) Run(builder *Builder) {
+	p.builder = builder
+	p.orphaned = make(map[types.NamespacedName]bool, len(p.orphaned))


To be safe, add:

defer func(){ p.builder = nil p.orphaned = nil }()

jpeach · 2020-09-01T01:03:49Z

internal/dag/builder_test.go

+
+func (p *pluggableProcessor) Run(builder *Builder) {
+	p.runFunc(builder)
+}


I've generally found it's pretty useful to add a function adaptor at the API layer, eg.

type BuildProcessorFunc func(*Builder) func (b BuildProcessorFunc) Build(builder *Builder) { if b != nil { b(builder) } }

Maybe add this in a subsequent PR?

jpeach · 2020-09-01T01:22:00Z

I'm pretty sure it's possible to just have processors make passes over the DAG and not have a separate build context. That would be my preferred solution.

Would you move the services, virtualhosts, securevirtualhosts maps that are currently in the Builder into the DAG struct along with the related methods that enable the Processors to easily check for/record existence of those objects? Or did you have a different approach in mind for how the Processors would interact with the DAG?

I think that some go into the DAG and some get subsumed by the resource cache.

I think there are some nice things about keeping the Builder/BuildContext and the final DAG separate - you can have a different API for builders of the DAG vs. consumers of the DAG, and also you know that a DAG object is always a "final" representation rather than in the process of being built.

I think that the DAG-only approach allows builders to be more independent. You can drop in a builder that manipulates the DAG without having to make corresponding changes to a build context. I suspect that in the medium term, this makes the API more robust.

youngnick

LGTM too.

Extracts the logic specific to processing HTTPProxy, Ingress APIs into their own processors that are invoked by the DAG builder. Also extracts a listener processor to add HTTP/HTTPS listeners after the other processors have run. Signed-off-by: Steve Kriss <[email protected]>

codecov · 2020-09-01T15:56:09Z

Codecov Report

Merging #2847 into main will increase coverage by 0.01%.
The diff coverage is 90.79%.

@@            Coverage Diff             @@
##             main    #2847      +/-   ##
==========================================
+ Coverage   76.44%   76.46%   +0.01%     
==========================================
  Files          74       77       +3     
  Lines        5804     5833      +29     
==========================================
+ Hits         4437     4460      +23     
- Misses       1272     1278       +6     
  Partials       95       95

Impacted Files	Coverage Δ
cmd/contour/serve.go	`2.44% <0.00%> (-0.06%)`	⬇️
internal/dag/httpproxy_processor.go	`91.27% <91.27%> (ø)`
internal/dag/ingress_processor.go	`92.78% <92.78%> (ø)`
internal/dag/builder.go	`91.66% <100.00%> (-0.14%)`	⬇️
internal/dag/listener_processor.go	`100.00% <100.00%> (ø)`
internal/dag/policy.go	`96.00% <100.00%> (+0.06%)`	⬆️
internal/featuretests/featuretests.go	`93.26% <100.00%> (+0.14%)`	⬆️

skriss requested review from jpeach, stevesloka and youngnick August 28, 2020 18:50

jpeach suggested changes Aug 31, 2020

View reviewed changes

internal/dag/builder.go Outdated Show resolved Hide resolved

internal/dag/builder.go Outdated Show resolved Hide resolved

internal/dag/builder.go Outdated Show resolved Hide resolved

skriss force-pushed the extract-processors branch from 360de45 to e70f244 Compare August 31, 2020 14:57

stevesloka approved these changes Aug 31, 2020

View reviewed changes

skriss mentioned this pull request Aug 31, 2020

internal/dag: set HTTPProxy with no routes/includes/tcpproxy invalid #2862

Merged

jpeach approved these changes Sep 1, 2020

View reviewed changes

youngnick approved these changes Sep 1, 2020

View reviewed changes

skriss force-pushed the extract-processors branch from e70f244 to 499d9d8 Compare September 1, 2020 15:51

skriss merged commit c6484b7 into projectcontour:main Sep 1, 2020

skriss mentioned this pull request Sep 2, 2020

internal/dag: Refactor builder #2226

Closed

skriss deleted the extract-processors branch September 8, 2020 20:34

internal/dag: extract DAG processors from the main builder #2847

internal/dag: extract DAG processors from the main builder #2847

Uh oh!

Conversation

skriss commented Aug 28, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jpeach left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

skriss commented Aug 31, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

stevesloka left a comment

Choose a reason for hiding this comment

Uh oh!

jpeach left a comment

Choose a reason for hiding this comment

Uh oh!

jpeach Sep 1, 2020

Choose a reason for hiding this comment

Uh oh!

jpeach Sep 1, 2020

Choose a reason for hiding this comment

Uh oh!

jpeach Sep 1, 2020

Choose a reason for hiding this comment

Uh oh!

jpeach Sep 1, 2020

Choose a reason for hiding this comment

Uh oh!

jpeach commented Sep 1, 2020

Uh oh!

youngnick left a comment

Choose a reason for hiding this comment

Uh oh!

codecov bot commented Sep 1, 2020

Codecov Report

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

skriss commented Aug 28, 2020 •

edited

Loading

skriss commented Aug 31, 2020 •

edited

Loading