-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Refactor aws dynamodb streams scaler #6089
base: main
Are you sure you want to change the base?
Refactor aws dynamodb streams scaler #6089
Conversation
Signed-off-by: dttung2905 <[email protected]>
Signed-off-by: dttung2905 <[email protected]>
targetShardCount int64 | ||
activationTargetShardCount int64 |
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.
@wozniakjan I'm leaving these out for now because the error logic handling is abit different in thise case. Instead of letting it failed on invalid input, this code just throws error and fallback to the default value
keda/pkg/scalers/aws_dynamodb_streams_scaler.go
Lines 97 to 114 in 66d4c95
if val, ok := config.TriggerMetadata["shardCount"]; ok && val != "" { | |
shardCount, err := strconv.ParseInt(val, 10, 64) | |
if err != nil { | |
meta.targetShardCount = defaultTargetDBStreamsShardCount | |
logger.Error(err, "error parsing dyanmodb stream metadata shardCount, using default %n", defaultTargetDBStreamsShardCount) | |
} else { | |
meta.targetShardCount = shardCount | |
} | |
} | |
if val, ok := config.TriggerMetadata["activationShardCount"]; ok && val != "" { | |
shardCount, err := strconv.ParseInt(val, 10, 64) | |
if err != nil { | |
meta.activationTargetShardCount = defaultActivationTargetDBStreamsShardCount | |
logger.Error(err, "error parsing dyanmodb stream metadata activationTargetShardCount, using default %n", defaultActivationTargetDBStreamsShardCount) | |
} else { | |
meta.activationTargetShardCount = shardCount | |
} | |
} |
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.
thanks for pointing this out, I'm ok with this. But if you and other @kedacore/keda-core-contributors are willing to make an exception with a breaking change here, I'd like to advocate for a throwing error here. Imho it leads to overall better UX after the initial surprise that something that used to work (incorrectly) no longer does.
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, I have no idea why did we allow this in a first place :) I don't like this kind of unexpected defaults. I am inclined in changing the behavior to error here.
WDYT @kedacore/keda-contributors ?
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 something undocumented a breaking change? IMHO it depends on the time that has been there, if it's something recent we can change it, but this has been there for 2 years, so we should keep it IMO
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 how about we add a deprecation message logic into this current line. After the next two release, we then deprecate it by this PR? Wdyt?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions. |
Refactor aws dynamodb streams scaler.
Checklist
Relates to #5797