-
Notifications
You must be signed in to change notification settings - Fork 755
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
base: master
Are you sure you want to change the base?
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #3570 +/- ##
==========================================
- Coverage 54.49% 47.85% -6.64%
==========================================
Files 134 229 +95
Lines 12329 19330 +7001
==========================================
+ Hits 6719 9251 +2532
- Misses 5116 9208 +4092
- Partials 494 871 +377
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
@@ -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
@abhipatnala can you move this code as well and the code block suggested by @ritazh in above comment? |
Signed-off-by: Avinash Patnala <[email protected]>
Signed-off-by: Avinash Patnala <[email protected]>
…ginal repo for testing Signed-off-by: Avinash Patnala <[email protected]>
… once we fallback to original framwork repo Signed-off-by: Avinash Patnala <[email protected]>
6efad9d
to
99c98e9
Compare
Signed-off-by: Avinash Patnala <[email protected]>
71230fd
to
80c7275
Compare
Signed-off-by: Avinash Patnala <[email protected]>
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 <[email protected]>
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: