-
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
fix: move sasl
and tls
flag to ScaledObject instead of specifying in TriggerAuthentication
#4322
fix: move sasl
and tls
flag to ScaledObject instead of specifying in TriggerAuthentication
#4322
Conversation
Also I have included a small fix for the static check failure for Azure Blob Scaler link ( Not quite relevant to this MR though but I try to make this pass the CI )
|
/run-e2e kafka* |
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.
LGTM!
Is this ready to review @dttung2905 ? I ask because it has WIP in the title |
sasl
and tls
flag to ScaledObject instead of specifying in TriggerAuthenticationsasl
and tls
flag to ScaledObject instead of specifying in TriggerAuthentication
CHANGELOG.md
Outdated
@@ -44,7 +44,7 @@ To learn more about active deprecations, we recommend checking [GitHub Discussio | |||
|
|||
### Breaking Changes | |||
|
|||
- TODO | |||
- **Kafka Scaler**: move `tls` and `sasl` in TriggerAuthentication to `enableTls` and `saslAuthType` in ScaledObject ([#4232](https://github.com/kedacore/keda/issues/4322)) |
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.
This should not be a breaking change as we discussed but more a new approach next to the deprecated approach. Would you mind updating the changelog and ensure this complies with https://github.com/kedacore/governance/blob/main/DEPRECATIONS.md
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 we will go with supporting both methods, I will move this to Improvements
section 🙏
Thanks for the super quick review on this! I put WIP because I still need to update the doc here , as @tomkerkhove pointed out (thanks Tom for that) |
Thanks a ton and no rush - Take your time! |
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.
Don't we want to support both approaches? (Instead of removing the old one?)
Personally, I would say we deprecate the old one and remove it in the next 2 releases. The reason is having multiple places to specify the same value just make it confusing to the user. Also |
Yeah, though the problem is, that in my opinion these settings use 90% of ScaledObjects with Kafka, which means a lot of users 😄 |
We have a clear policy about that, we should keep both options during the deprecation period but AFAI see, you have kept both https://github.com/kedacore/keda/pull/4322/files#diff-03cf62956adcec86c0717723ab146472f0979221b0e5942a6e5460fa6d5e4f08R180-R196. Am I right? |
What @zroubalik proposed it that we keep the old method forever and not deprecate at all . |
Yeah, I think that we should keep both options present. Some users might want to specify these settings in TriggerAuth. I vote for not deprecating. |
I don't have any strong opinion, but it's true that it isn't a secret, so doesn't make sense treating it as a secret and maybe dropping the support is worth to make the things more clear |
@tomkerkhove what is your opinion on this :P ? I support smooth developer experience so there are two sides of the coin ( clarify vs disruption ). I can keep both and not deprecate the old method too if Tom is not strongly against it In the future, if there are feedbacks from user about confusions of several methods, we can go back and deprecate the old one. For me its not fixed anyways 🙏 |
I don't have an opinion on this, I'm fine with either |
Thanks, so let's not deprecate :) |
Fine for me! |
Let's make sure this is also removed from the docs |
679028c
to
082c171
Compare
/run-e2e kafka* |
pkg/scalers/kafka_scaler.go
Outdated
case config.TriggerMetadata["saslAuthType"] != "": | ||
saslAuthType = config.TriggerMetadata["saslAuthType"] |
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.
Why don't just use the same key? sasl
should be better as it's the same key, recovered from both places
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.
Good catch! Agree, we should use the same key for both TA and trigger metadata.
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.
Agree with that as I cross commented on the doc PR. Also it means that for tls the value should be enable/disable instead of true/false right? Just want to confirm this
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.
Let's reuse the very same apporach that already present wrt key/value naming please :)
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 can think about deprecation/renaming later on. But let's be consistent.
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, the valid values shouldn't change from previous state
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.
Got it. Thanks for the review. I will try do it later once im back to keyboard
pkg/scalers/kafka_scaler.go
Outdated
@@ -151,30 +165,48 @@ func parseKafkaAuthParams(config *ScalerConfig, meta *kafkaMetadata) error { | |||
} | |||
|
|||
meta.enableTLS = false | |||
enableTLS := false | |||
if val, ok := config.TriggerMetadata["enableTls"]; ok { |
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.
Why don't just use the same key? tls
should be better as it's the same key, recovered from both places
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.
looking good, just rename the keys please
…erAuthentication Signed-off-by: dttung2905 <[email protected]>
Signed-off-by: dttung2905 <[email protected]>
Signed-off-by: dttung2905 <[email protected]>
Signed-off-by: dttung2905 <[email protected]>
Signed-off-by: dttung2905 <[email protected]>
Signed-off-by: dttung2905 <[email protected]>
Signed-off-by: dttung2905 <[email protected]>
82f3f04
to
fe03c6d
Compare
Signed-off-by: dttung2905 <[email protected]>
/run-e2e kafka* |
… in TriggerAuthentication (kedacore#4322) Signed-off-by: dttung2905 <[email protected]>
Hi team,
This MR will solve
Provide a description of what has been changed
Checklist
enableTls
andsaslAuthType
for Kafka Scaler ScaledObject keda-docs#1016Example:
Fixes #3611
Relates to #