Promote the shared injection check to the CLI and webhook#2555
Promote the shared injection check to the CLI and webhook#2555
Conversation
alpeb
left a comment
There was a problem hiding this comment.
All these refactorings certainly improve the quality of the code, thanks for taking care of this!
I added some comments below from a first review pass.
| if !nonEmpty { | ||
| r := inject.Report{UnsupportedResource: true} | ||
| return bytes, []inject.Report{r}, nil | ||
| reports := []inject.Report{*report} |
There was a problem hiding this comment.
It appears we can deal with a single report (instead of having to always wrap in an single-item array) everywhere except in the inject_utils.go functions. That got evident in on of my branches, so I decided to tackle that later in a separate PR, but you can do that here as well if you find it's a natural change 😉
| ns: nsDisabled, | ||
| conf: confNsDisabled(), | ||
| expected: false, | ||
| }, |
There was a problem hiding this comment.
Is it enough to add the additional Injectable() test below to be able to re-enable these tests, or is it more complicated than that? If so we could track that as a separate item for the 2.3 test sprint to expedite this PR ⚡
There was a problem hiding this comment.
These two test cases are no longer useful, as the results will always be true because GetPatch() no longer checks if injection should happen. Some of these tests need to be revisited, as they aren't testing anything webhook related, but not in this PR.
d2d43ae to
0b11a25
Compare
|
Integration test results for d2d43ae: success 🎉 |
|
Integration test results for 0b11a25: success 🎉 |
…webhook Performing this check earlier helps to separate the specialized logic to the CLI and webhook. Any subsequent modification of this check logic to support config override of existing meshed workload will be confined to the relevant component. The shared lib can then focus only on config overrides. Signed-off-by: Ivan Sim <[email protected]>
Signed-off-by: Ivan Sim <[email protected]>
Signed-off-by: Ivan Sim <[email protected]>
Signed-off-by: Ivan Sim <[email protected]>
0b11a25 to
31c413c
Compare
alpeb
left a comment
There was a problem hiding this comment.
This looks and tests well for me ![]()
|
Integration test results for 31c413c: success 🎉 |
Signed-off-by: Ivan Sim <[email protected]>
|
Integration test results for 3b45283: success 🎉 |
klingerf
left a comment
There was a problem hiding this comment.
Nice, the approach seems a lot cleaner overall. But I think we've regressed on the logic that determines whether or not the webhook should inject a pod -- see my comment below.
siggy
left a comment
There was a problem hiding this comment.
looks good! left a couple related comments...
774c8b7 to
b312215
Compare
|
Integration test results for b312215: success 🎉 |
b312215 to
3b45283
Compare
|
Integration test results for 3b45283: success 🎉 |
10f0545 to
3fa3972
Compare
|
Integration test results for 3fa3972: success 🎉 |
Signed-off-by: Ivan Sim <[email protected]>
3fa3972 to
3095a77
Compare
|
Integration test results for 3095a77: success 🎉 |
Signed-off-by: Ivan Sim <[email protected]>
Signed-off-by: Ivan Sim <[email protected]>
feede5c to
b340ec7
Compare
|
Integration test results for b340ec7: success 🎉 |
Signed-off-by: Ivan Sim <[email protected]>
|
Integration test results for 6b26976: success 🎉 |
This PR refactors the
shouldInjectlogic by promoting it from the sharedpkg/injectlibrary to the CLI and webhook.Performing this check earlier helps to separate the specialized logic to the CLI and webhook. Subsequent modification to this check to support configs override of existing meshed workloads will be confined to the relevant component.
This PR addresses point 1 to 3 of our previous discussion on configs override in 2500.
Signed-off-by: Ivan Sim [email protected]