-
Notifications
You must be signed in to change notification settings - Fork 103
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 comparing parameter values on Instance Spec updates #348
Conversation
Summary: previously we would only recognize Instance Spec parameter updates and fail to detect an update if a parameter would be added or removed. This is fixed now. Issue: #216
planName = param.Trigger | ||
ok = true | ||
} | ||
for k := range parameterDifference(old.Spec.Parameters, new.Spec.Parameters) { |
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.
Will this run 2 PlanExecutions
if we change 2 different parameters?n . I think that might be problematic.
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.
Yep, this is what I wanted to discuss in this PR. Keep in mind that this part of the logic hasn't changed so we have this problem with current master. Actually, there are two questions:
- If the user removes a parameter, do we still trigger the original
param.Trigger
plan? Do we trigger anything? - With multiple changes, multiple plans might be triggered - do we take first/last/random or do we forbid such changes?
Thoughts? /cc @gerred
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 think always one plan is triggered, but which one is it is decided by the last parameter change :/
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 need to think about this, I'll weigh in today.
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.
Keep in mind that this part of the logic hasn't changed
You're right, currently the value of planName
gets used later, sothe "last" element that gets changed is the one that runs.
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.
If the user removes a parameter, do we still trigger the original param.Trigger plan? Do we trigger anything?
I think we would run the plan associated to the parameter taht was "changed" e.g. present -> not present, unless the default value for the parameter was the same as the value that existed
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 probably don't need to fix this here though. Would be good to have issue tracking this though. I think the current thinking is to add validation that will disallow changing parameters that would end up triggering different plans
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.
Agreed. We separate this out from this PR.
// Fetch the Framework instance | ||
instance := &kudov1alpha1.Framework{} | ||
err := r.Get(context.TODO(), request.NamespacedName, instance) | ||
// Fetch the framework |
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.
hehe I smell copy-paste here :D nice 👍
planName = param.Trigger | ||
ok = true | ||
} | ||
for k := range parameterDifference(old.Spec.Parameters, new.Spec.Parameters) { |
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 think always one plan is triggered, but which one is it is decided by the last parameter change :/
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.
🚢
planName = param.Trigger | ||
ok = true | ||
} | ||
for k := range parameterDifference(old.Spec.Parameters, new.Spec.Parameters) { |
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.
Agreed. We separate this out from this PR.
Strictly speaking, its the first parameter change right now. |
Summary:
previously we would only recognize Instance Spec parameter updates and fail to detect an update if a parameter would be added or removed. This is fixed now.
What type of PR is this?
/kind bug
What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes #216
Special notes for your reviewer:
Does this PR introduce a user-facing change?: