Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

internal: Add support for watching ingress/v1 resources #3266

Merged
merged 1 commit into from
Feb 3, 2021

Conversation

stevesloka
Copy link
Member

Add support for watching networking.k8s.io/v1 Ingress resources and add/remove
from internal Cache later allowing these objects to be implemented.

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

@stevesloka stevesloka requested a review from a team as a code owner January 20, 2021 19:10
@stevesloka stevesloka requested review from sunjayBhatia, youngnick and skriss and removed request for a team January 20, 2021 19:10
@codecov
Copy link

codecov bot commented Jan 20, 2021

Codecov Report

Merging #3266 (037a964) into main (721652f) will decrease coverage by 0.12%.
The diff coverage is 73.52%.

Impacted file tree graph

@@            Coverage Diff             @@
##             main    #3266      +/-   ##
==========================================
- Coverage   75.43%   75.30%   -0.13%     
==========================================
  Files          98       98              
  Lines        6162     6249      +87     
==========================================
+ Hits         4648     4706      +58     
- Misses       1409     1436      +27     
- Partials      105      107       +2     
Impacted Files Coverage Δ
cmd/contour/serve.go 0.00% <0.00%> (ø)
internal/annotation/annotations.go 100.00% <ø> (ø)
internal/dag/policy.go 96.50% <ø> (ø)
internal/k8s/informers.go 0.00% <0.00%> (ø)
internal/dag/cache.go 90.96% <77.33%> (-4.24%) ⬇️
internal/dag/ingress_processor.go 93.85% <100.00%> (+0.40%) ⬆️
internal/k8s/log.go 63.04% <0.00%> (-6.53%) ⬇️

@stevesloka
Copy link
Member Author

Please hold on this for a second, I'm going to add IngressClass as well which is needed along with ingress/v1.

@stevesloka stevesloka added this to the 1.12.0 milestone Jan 21, 2021
@stevesloka
Copy link
Member Author

Integration tests are failing because of RBAC. =)

cmd/contour/serve.go Outdated Show resolved Hide resolved
cmd/contour/serve.go Outdated Show resolved Hide resolved
internal/dag/cache.go Show resolved Hide resolved
internal/dag/cache.go Outdated Show resolved Hide resolved
internal/dag/cache.go Outdated Show resolved Hide resolved
internal/dag/ingress_processor.go Outdated Show resolved Hide resolved
internal/dag/ingress_processor.go Outdated Show resolved Hide resolved
@stevesloka
Copy link
Member Author

Ok turns out testing against a kind v1.16.4 cluster (image: kindest/node:v1.16.4@sha256:b91a2c2317a000f3a783489dfb755064177dbc3a0b2f4147d50f04825d016f55) doesn't let Envoy connect to Contour, but using a v1.16.9 image (kindest/node:v1.16.9@sha256:7175872357bc85847ec4b1aba46ed1d12fa054c83ac7a8a11f5c268957fd5765) does.

I was down a rabbit hole chasing the wrong issue. =)

@stevesloka stevesloka marked this pull request as draft January 25, 2021 01:39
Copy link
Member

@youngnick youngnick left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is looking good! I like explicitly translating v1beta1 Ingress objects into v1 objects internally, that makes things easier.

@stevesloka
Copy link
Member Author

@skriss I updated with your comments in the initial review. The method now is I have a converter which turns all v1beta1 ingress objects into v1 ingress types. From that point, all the processing is the same.

@stevesloka stevesloka force-pushed the watchIngressv1 branch 2 times, most recently from d71bf23 to 744112c Compare January 25, 2021 15:56
@stevesloka stevesloka marked this pull request as ready for review January 25, 2021 15:56
Copy link
Member

@skriss skriss left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@stevesloka I think this is looking pretty good. Looks like it'll address a few of the sub-issues listed in #2135 (comment), and then we'll likely have to follow up on a few more.

internal/dag/cache.go Show resolved Hide resolved
internal/dag/ingress_processor.go Show resolved Hide resolved
internal/dag/cache.go Show resolved Hide resolved
Copy link
Member

@skriss skriss left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

couple more comments on the converter function

internal/dag/cache.go Show resolved Hide resolved
internal/dag/cache.go Outdated Show resolved Hide resolved
internal/dag/cache.go Outdated Show resolved Hide resolved
internal/dag/cache.go Show resolved Hide resolved
@@ -104,154 +105,185 @@ func TestDAGInsert(t *testing.T) {
},
}

i1 := &v1beta1.Ingress{
i1V1 := &networking_v1.Ingress{
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this file's diff is pretty impossible to review - can you describe the changes? I think you said you were creating a second copy of all the Ingress tests, that used a v1 Ingress instead of a v1beta1, so we'd have tests for both the v1beta1 and the v1 representations.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah it's unfortunate that the diff is so hard to read, but I copied all the v1beta1 ingress resources into networking_v1 ingress resources and corresponding tests so that we could test the v1beta1 resources along with the networking_v1 resources.

In the next set of PRs, we should expand these tests with the new features in v1 (e.g. ingressclass, path type, etc)

Copy link
Member

@skriss skriss left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks pretty good to me. Do you want to hold it until after we release 1.12, so we can get a few extra test cycles in on it (along with the additional items for full v1 support)?

@stevesloka
Copy link
Member Author

This looks pretty good to me. Do you want to hold it until after we release 1.12, so we can get a few extra test cycles in on it (along with the additional items for full v1 support)?

Yup we can hold, this PR doesn't add anything to the release at the moment.

internal/dag/cache.go Show resolved Hide resolved
@sunjayBhatia
Copy link
Member

This looks pretty good to me. Do you want to hold it until after we release 1.12, so we can get a few extra test cycles in on it (along with the additional items for full v1 support)?

+1 just a small comment

Copy link
Member

@youngnick youngnick left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This LGTM, but agree that we should hold until after 1.12 releases.

@youngnick youngnick modified the milestones: 1.12.0, 1.13.0 Jan 29, 2021
@skriss
Copy link
Member

skriss commented Feb 3, 2021

ready for a rebase & merge

@skriss
Copy link
Member

skriss commented Feb 3, 2021

Needs a make generate.

@stevesloka
Copy link
Member Author

Needs a make generate.

Yup! Just did that and pushed, should work now.

Add support for watching networking.k8s.io/v1 Ingress & IngressClass resources
and add/remove from internal cache later allowing these objects to be implemented.

Signed-off-by: Steve Sloka <[email protected]>
@stevesloka stevesloka force-pushed the watchIngressv1 branch 2 times, most recently from 9f6d94e to 556d138 Compare February 3, 2021 16:04
Copy link
Member

@sunjayBhatia sunjayBhatia left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I might be missing where the logic for this is, but do we have coverage for when an IngressClass object is removed? Should we be removing all the Ingress objects that reference that IngressClass from the cache etc.?

I was initially going to say the above but read through #2146 before clicking submit. Given we agreed to add all Ingress objects to the cache and only add them to the DAG if they apply, this LGTM

@stevesloka
Copy link
Member Author

I'm trying to make smaller commits for this stuff so it's easier to read. Now that we have the plumbing to get the objects, we can now operate against them. Thanks for the reviews @skriss & @sunjayBhatia! 🎉

@stevesloka
Copy link
Member Author

@skriss are you good with the converter bits? There were changes requested so wanted to double-check.

Copy link
Member

@skriss skriss left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants