-
Notifications
You must be signed in to change notification settings - Fork 104
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
KEP-20 part 2: trigger plans manually #1352
Conversation
bff7f29
to
a441ee6
Compare
Summary: - current `ValidationWebhookConfiguration` is replaced by `MutatingWebhookConfiguration` to allow instance admission webhook to set the `Spec.PlanExecution.PlanName` - `Spec.PlanExecution.PlanName` is now not required anymore Note: - Instance CRD got updated - breaking change: ValidationWebhookConfiguration from previous KUDO version (in case webhooks were used) has to be removed manually Signed-off-by: Aleksey Dukhovniy <alex.dukhovniy@googlemail.com>
so that when the same plan is re-triggered a new UID is generated and the controller can restart the plan. Signed-off-by: Aleksey Dukhovniy <alex.dukhovniy@googlemail.com>
…instance additionally, instance controller now properly handles the cases where the webhooks are enabled and where they are disabled. Signed-off-by: Aleksey Dukhovniy <alex.dukhovniy@googlemail.com>
Signed-off-by: Aleksey Dukhovniy <alex.dukhovniy@googlemail.com>
@@ -116,6 +128,85 @@ func (i *Instance) PlanStatus(plan string) *PlanStatus { | |||
return nil | |||
} | |||
|
|||
// annotateSnapshot stores the current spec of Instance into the snapshot annotation |
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.
Moved here from the instance_controller
as they're needed in the webhook too.
new command `kudoctl plan trigger --name=<planNam> --instance=<instanceName>` is now available Signed-off-by: Aleksey Dukhovniy <alex.dukhovniy@googlemail.com>
Signed-off-by: Aleksey Dukhovniy <alex.dukhovniy@googlemail.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.
First pass, more to come
// 2. Cleanup plan exists in the operator version and has *never run* before | ||
// 3. Cleanup hasn't been scheduled yet (first time the deletion is being reconciled) | ||
// we set the Spec.PlanExecution.PlanName = 'cleanup' | ||
hasToScheduleCleanupAfterDeletion := func() bool { |
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 there a specific reason that these are inline funcs? I'd rather have them outside as actual funcs or just plain code in this method.
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.
Since they're only used once inside this method, they would otherwise "pollute" the controller namespace. I prefer to inline them to give a "speaking name" to otherwise complicated 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.
Yeah, I get the "pollution" argument, although I blame go for it ;)
Still, I wouldn't mind having just the simple booleans inside this func instead of full functions that are only called once, but it's not a blocker for me. Just looks weird.
Signed-off-by: Aleksey Dukhovniy <alex.dukhovniy@googlemail.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.
I'm not sure if we should keep the webhooks optional now, but... This looks ok so far.
// 2. Cleanup plan exists in the operator version and has *never run* before | ||
// 3. Cleanup hasn't been scheduled yet (first time the deletion is being reconciled) | ||
// we set the Spec.PlanExecution.PlanName = 'cleanup' | ||
hasToScheduleCleanupAfterDeletion := func() bool { |
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, I get the "pollution" argument, although I blame go for it ;)
Still, I wouldn't mind having just the simple booleans inside this func instead of full functions that are only called once, but it's not a blocker for me. Just looks weird.
I'd like to see at least one more review on this though. It's a big PR ;) |
absolutely! 💯 |
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 was not able to finish the review, will come back to it tomorrow, sorry
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.
Did my first full pass :) I need to go over the webhook logic one more.
Most comments are nits, there are two bigger things I think we should take a look at (controller logic + that namespace default)
Overall nice work 👏
Proper namespace handling for CREATEd instances, robust detection of instances deletion life-cycle and logging improvements Signed-off-by: Aleksey Dukhovniy <alex.dukhovniy@googlemail.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.
👏 nice work, the logic is very complex but you did a great job documenting it!
My only bigger concern is - you cannot trigger plan when running kudo without webhooks. I was always thinkig about the whole thing in this way:
- kudo without webhooks is only suitable for newcomers who want to quickly start something locally and run some very basic operator like cowsay and see what kudo is doing and play around with its features OR for developers of operators who run local and know what they are doing since no webhooks are not giving you consistency guarantees
- with webhooks for ALL OTHER CASES
I think it will be misleading that you can trigger plans only for kudo running in cluster and with webhooks.
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.
Mostly nitpicks here and there, but the thing I'm concerned about is that we're adding a very complex component without integration tests.
The bottom line is: KUDO API is edge-based which suits a lot of real-world practical scenarios really good. However, the only way KUDO operations stay consistent (and e.g. avoid data loss) is by guarding them with the webhook. While it was possible to run into inconsistent behavior without manually triggering plans, the later definitely exaggerates it. I'm strongly against allowing it without webhooks. |
Then please at least make it obvious that it's not allowed from CLI, not just silently ignore it. Also document it with the reasoning 🙏 thanks |
Signed-off-by: Aleksey Dukhovniy <alex.dukhovniy@googlemail.com>
I addressed all smaller issues and the bigger one (e2e test) will be a followup PR
Summary: - current `ValidationWebhookConfiguration` is replaced by `MutatingWebhookConfiguration`. Instance admission webhook is now setting the `Spec.PlanExecution.PlanName` on updates/creates - `kudo-manager-instance-validation-webhook-config` webhook (when active) is enforcing all rules around triggering plans directly (manually) and indirectly (through Instance updates), making sure that no conflicting plans are running - new CLI command `$ kubectl kudo plan trigger --name deploy --instance dummy-instance` is available to trigger a plan manually - manually triggering plans is only possible when webhooks are enabled (`kudo init --webhook=InstanceValidation ...`) **Notes**: - **change**: Instance CRD got updated - **heavy change**: `ValidationWebhookConfiguration` from previous KUDO version (in case webhooks were used) has to be removed manually <!-- Thanks for sending a pull request! Here are some tips for you: 1. If this is your first time, please read our contributor guidelines: https://github.com/kudobuilder/kudo/blob/master/CONTRIBUTING.md 2. Make sure you have added and ran the tests before submitting your PR 3. If the PR is unfinished, start it as a Draft PR: https://github.blog/2019-02-14-introducing-draft-pull-requests/ --> **What this PR does / why we need it**: <!-- *Automatically closes linked issue when PR is merged. Usage: `Fixes #<issue number>`, or `Fixes (paste link of issue)`. --> Fixes #649 #741 Signed-off-by: Thomas Runyon <runyontr@gmail.com>
Summary:
ValidationWebhookConfiguration
is replaced byMutatingWebhookConfiguration
. Instance admission webhook is now setting theSpec.PlanExecution.PlanName
on updates/createskudo-manager-instance-validation-webhook-config
webhook (when active) is enforcing all rules around triggering plans directly (manually) and indirectly (through Instance updates), making sure that no conflicting plans are running$ kubectl kudo plan trigger --name deploy --instance dummy-instance
is available to trigger a plan manuallykudo init --webhook=InstanceValidation ...
)Note:
ValidationWebhookConfiguration
from previous KUDO version (in case webhooks were used) has to be removed manuallyWhat this PR does / why we need it:
Fixes #649 #741