-
Notifications
You must be signed in to change notification settings - Fork 690
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
Conversation
Codecov Report
@@ 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
|
Please hold on this for a second, I'm going to add IngressClass as well which is needed along with ingress/v1. |
39e64ba
to
f40e557
Compare
Integration tests are failing because of RBAC. =) |
Ok turns out testing against a kind v1.16.4 cluster (image: I was down a rabbit hole chasing the wrong issue. =) |
e278946
to
01e89be
Compare
There was a problem hiding this 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.
0d29616
to
1168405
Compare
@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. |
d71bf23
to
744112c
Compare
There was a problem hiding this 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.
There was a problem hiding this 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
231c9f5
to
42307d6
Compare
@@ -104,154 +105,185 @@ func TestDAGInsert(t *testing.T) { | |||
}, | |||
} | |||
|
|||
i1 := &v1beta1.Ingress{ | |||
i1V1 := &networking_v1.Ingress{ |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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)
There was a problem hiding this 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)?
Yup we can hold, this PR doesn't add anything to the release at the moment. |
+1 just a small comment |
42307d6
to
83db520
Compare
There was a problem hiding this 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.
ready for a rebase & merge |
83db520
to
9f6d94e
Compare
Needs a |
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]>
9f6d94e
to
556d138
Compare
There was a problem hiding this 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
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! 🎉 |
@skriss are you good with the converter bits? There were changes requested so wanted to double-check. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
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]