Skip to content
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

Merged

Conversation

dttung2905
Copy link
Contributor

@dttung2905 dttung2905 commented Mar 4, 2023

Hi team,
This MR will solve

Provide a description of what has been changed

Checklist

Example:

triggers:
- type: kafka
  metadata:
    bootstrapServers: kafka.svc:9092
    consumerGroup: my-group
    topic: test-topic
    lagThreshold: '5'
    activationLagThreshold: '3'
    offsetResetPolicy: latest
    allowIdleConsumers: false
    scaleToZeroOnInvalidOffset: false
    excludePersistentLag: false
    version: 1.0.0
+   saslAuthType: plaintext|scram_sha256|scram_sha512|oauthbearer|none
+   enableTls: true|false

Fixes #3611

Relates to #

@dttung2905
Copy link
Contributor Author

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 )

pkg/scalers/azure_blob_scaler.go:142:111: string `true` has 3 occurrences, but such constant `stringTrue` already exists (goconst)
	if val, ok := config.TriggerMetadata["useAAdPodIdentity"]; ok && config.PodIdentity.Provider == "" && val == "true" {
	                                                                                                             ^

Error: Process completed with exit code 1.

@JorTurFer
Copy link
Member

JorTurFer commented Mar 6, 2023

/run-e2e kafka*
Update: You can check the progress here

Copy link
Member

@JorTurFer JorTurFer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@JorTurFer
Copy link
Member

JorTurFer commented Mar 6, 2023

Is this ready to review @dttung2905 ? I ask because it has WIP in the title

@dttung2905 dttung2905 changed the title [WIP] fix: move sasl and tls flag to ScaledObject instead of specifying in TriggerAuthentication fix: move sasl and tls flag to ScaledObject instead of specifying in TriggerAuthentication Mar 7, 2023
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))
Copy link
Member

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

Copy link
Contributor Author

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 🙏

@dttung2905
Copy link
Contributor Author

Is this ready to review @dttung2905 ? I ask because it has WIP in the title

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)
I will update the doc PR later and the CHANGELOG as well

@tomkerkhove
Copy link
Member

Thanks a ton and no rush - Take your time!

Copy link
Member

@zroubalik zroubalik left a 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?)

@dttung2905
Copy link
Contributor Author

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 tls: enable and sasl:scram_sha256 are not really secrets so it might be weird to park it under TriggerAuthentication. What do you think @JorTurFer @tomkerkhove ?

@zroubalik
Copy link
Member

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 tls: enable and sasl:scram_sha256 are not really secrets so it might be weird to park it under TriggerAuthentication. What do you think @JorTurFer @tomkerkhove ?

Yeah, though the problem is, that in my opinion these settings use 90% of ScaledObjects with Kafka, which means a lot of users 😄

@JorTurFer
Copy link
Member

What do you think @JorTurFer @tomkerkhove ?

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?

@dttung2905
Copy link
Contributor Author

What do you think @JorTurFer @tomkerkhove ?

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 .

@zroubalik
Copy link
Member

What do you think @JorTurFer @tomkerkhove ?

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.

@JorTurFer
Copy link
Member

JorTurFer commented Mar 7, 2023

What do you think @JorTurFer @tomkerkhove ?

We have a clear policy about that, we should keep both options during the deprecation period but AFAI see, you have kept both #4322 (files). Am I right?

What @zroubalik proposed it that we keep the old method forever and not deprecate at all .

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

@dttung2905
Copy link
Contributor Author

dttung2905 commented Mar 8, 2023

@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 🙏

@tomkerkhove
Copy link
Member

I don't have an opinion on this, I'm fine with either

@zroubalik
Copy link
Member

Thanks, so let's not deprecate :)

@tomkerkhove
Copy link
Member

Fine for me!

@tomkerkhove
Copy link
Member

Let's make sure this is also removed from the docs

@dttung2905 dttung2905 force-pushed the fix-kafka-scaler-sasl-tls-setting branch from 679028c to 082c171 Compare March 8, 2023 16:18
@zroubalik
Copy link
Member

zroubalik commented Mar 8, 2023

/run-e2e kafka*
Update: You can check the progress here

JorTurFer
JorTurFer approved these changes Mar 9, 2023
Comment on lines 126 to 127
case config.TriggerMetadata["saslAuthType"] != "":
saslAuthType = config.TriggerMetadata["saslAuthType"]
Copy link
Member

@JorTurFer JorTurFer Mar 9, 2023

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

Copy link
Member

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.

Copy link
Contributor Author

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

Copy link
Member

@zroubalik zroubalik Mar 9, 2023

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 :)

Copy link
Member

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.

Copy link
Member

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

Copy link
Contributor Author

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

@@ -151,30 +165,48 @@ func parseKafkaAuthParams(config *ScalerConfig, meta *kafkaMetadata) error {
}

meta.enableTLS = false
enableTLS := false
if val, ok := config.TriggerMetadata["enableTls"]; ok {
Copy link
Member

@JorTurFer JorTurFer Mar 9, 2023

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

Copy link
Member

@zroubalik zroubalik left a 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

@dttung2905 dttung2905 force-pushed the fix-kafka-scaler-sasl-tls-setting branch from 82f3f04 to fe03c6d Compare March 9, 2023 14:34
Signed-off-by: dttung2905 <[email protected]>
@zroubalik
Copy link
Member

zroubalik commented Mar 9, 2023

/run-e2e kafka*
Update: You can check the progress here

@zroubalik zroubalik merged commit 846a4d0 into kedacore:main Mar 9, 2023
xoanmm pushed a commit to xoanmm/keda that referenced this pull request Mar 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Apache Kafka scaler: sasl and tls config are not secrets
4 participants