-
Notifications
You must be signed in to change notification settings - Fork 762
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
fix: Move K8scel driver from framework #3570
fix: Move K8scel driver from framework #3570
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #3570 +/- ##
==========================================
- Coverage 54.49% 47.58% -6.92%
==========================================
Files 134 236 +102
Lines 12329 19717 +7388
==========================================
+ Hits 6719 9382 +2663
- Misses 5116 9456 +4340
- Partials 494 879 +385
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
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.
is k8scel driver going to be removed from frameworks after these changes are in GK?
I think we should move "VAP related" code - https://github.com/open-policy-agent/gatekeeper/blob/master/pkg/controller/constraint/constraint_controller.go#L623 to EOF - under transform. wdyt? @open-policy-agent/gatekeeper-maintainers
Ideally this PR should test against a PR in framework that removes the k8scel driver to ensure all k8scel changes are migrated from framework to GK.
+1 and https://github.com/open-policy-agent/gatekeeper/blob/master/pkg/controller/constrainttemplate/constrainttemplate_controller.go#L750 will need to be moved too |
639f1b5
to
6efad9d
Compare
go.mod
Outdated
@@ -2,6 +2,8 @@ module github.com/open-policy-agent/gatekeeper/v3 | |||
|
|||
go 1.22.0 | |||
|
|||
replace github.com/open-policy-agent/frameworks/constraint v0.0.0-20240927180816-0f64229c5539 => github.com/abhipatnala/frameworks/constraint v0.0.0-20241010172729-61e15952c5c5 |
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.
@abhipatnala can you pls open a PR on framework as well so we can review and get it merged before merging this one? thanks!
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.
@ritazh Here is the Pr for removing cel driver from framework: open-policy-agent/frameworks#486
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.
@abhipatnala PTAL and remove the go.mod override 😄
@abhipatnala can you move this code as well and the code block suggested by @ritazh in above comment? |
Signed-off-by: Avinash Patnala <avinashpatnala@google.com>
Signed-off-by: Avinash Patnala <avinashpatnala@google.com>
…ginal repo for testing Signed-off-by: Avinash Patnala <avinashpatnala@google.com>
… once we fallback to original framwork repo Signed-off-by: Avinash Patnala <avinashpatnala@google.com>
6efad9d
to
99c98e9
Compare
Signed-off-by: Avinash Patnala <avinashpatnala@google.com>
71230fd
to
80c7275
Compare
Signed-off-by: Avinash Patnala <avinashpatnala@google.com>
80c7275
to
fcde683
Compare
I have updated the pr with those changes @ritazh @JaydipGabani |
Actually, reflecting on moving vapForVersion and vapBindingForVersion, I think those should stay with the controller code. This is because they are entirely used by the controllers as a way to govern which API version they use to communicate with the API server and are tightly coupled to the implementation of the controllers themselves. Under the theory that centralized code should have official versions that it supports (usually versionless), we should avoid introducing versioning semantics anywhere other than the edge (i.e. immediately before requests are sent to K8s). Arguably this is also true for the IsVapAPIEnabled as well, but at least there the code is shared, so having a common import path makes sense. I don't like the idea of the drivers/k8scel package interacting with the API server directly (this makes its functionality selectively portable to other use cases like Gator), but there is no great central owner. Leaving it in constraint controller also works. |
NOT moving the functions defined in the constraint/template controller would also limit merge conflicts with Jaydip's PR adding time delay to binding creation. |
Signed-off-by: Avinash Patnala <avinashpatnala@google.com>
var GroupVersion *schema.GroupVersion | ||
// var VapAPIEnabled *bool | ||
|
||
// var GroupVersion *schema.GroupVersion |
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.
pls remove commented code.
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.
Done
return false, nil | ||
} | ||
|
||
func vapBindingForVersion(gvk schema.GroupVersion) (client.Object, error) { |
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 agree with @maxsmythe on
Actually, reflecting on moving vapForVersion and vapBindingForVersion, I think those should stay with the controller code.
Let's not move there two methods.
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.
Done
@@ -747,17 +747,6 @@ func makeGvk(kind string) schema.GroupVersionKind { | |||
} | |||
} | |||
|
|||
func vapForVersion(gvk *schema.GroupVersion) (client.Object, error) { |
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 agree with @maxsmythe on
Actually, reflecting on moving vapForVersion and vapBindingForVersion, I think those should stay with the controller code.
Let's not move there two methods.
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.
done
Signed-off-by: Avinash Patnala <avinashpatnala@google.com>
Signed-off-by: Avinash Patnala <avinashpatnala@google.com>
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.
Two changes, otherwise LGTM.
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.
v1beta1ToV1
should be moved to transform
probably under make_vap_object.go
, since it acts as "constructor" for v1 VAP.
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.
v1beta1ToV1
should be moved to transform probably under make_vap_object.go
, since it acts as "constructor" for v1 VAPB.
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.
We should probably just wait for the scheme.Convert() bug to be fixed, as that's the "proper K8s" way to convert across versions. In general, core libraries should deal only with unversioned representations.
This has the added advantage of reducing merge conflicts with your PR.
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.
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'm ok with leaving it as is. but can we add a TODO comment for the bug and open an issue so we can come back to it later to clean it up? @JaydipGabani
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 added the TODO -
// TODO(jgabani): Use r.scheme.Convert to convert from v1beta1 to v1 once the conversion bug is fixed - https://github.com/kubernetes/kubernetes/issues/126582 |
This is the response I got "Conversion is only defined to the internal "hub" API type, not directly from one external version to another, and is only done by the api server, not by clients." I will follow up with api-server to see if this is something that can be fixed.
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.
hmm then sounds like its not a bug. not a blocker for this PR tho.
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 once gomod override is removed.
Signed-off-by: Avinash Patnala <avinashpatnala@google.com>
@@ -15,7 +15,8 @@ require ( | |||
github.com/google/uuid v1.6.0 | |||
github.com/onsi/gomega v1.34.1 | |||
github.com/open-policy-agent/cert-controller v0.11.0 | |||
github.com/open-policy-agent/frameworks/constraint v0.0.0-20240927180816-0f64229c5539 | |||
github.com/open-policy-agent/frameworks/constraint v0.0.0-20241007142041-e84361fed758 |
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.
@abhipatnala this should point to e78c8abd754aa12538eb21ee0c145cbe5465569d
What this PR does / why we need it:
Which issue(s) this PR fixes (optional, using
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when the PR gets merged):Fixes #3500
Special notes for your reviewer: