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

Refactor redis scaler config #5997

Merged
merged 8 commits into from
Sep 26, 2024

Conversation

SpiritZhou
Copy link
Contributor

@SpiritZhou SpiritZhou commented Jul 30, 2024

  1. Add multi name support in config type
  2. Refactor redis scaler config

Provide a description of what has been changed

Checklist

Relates to # #5797

Signed-off-by: SpiritZhou <iammrzhouzhenghan@gmail.com>
@SpiritZhou
Copy link
Contributor Author

SpiritZhou commented Jul 30, 2024

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

Signed-off-by: SpiritZhou <iammrzhouzhenghan@gmail.com>
@SpiritZhou SpiritZhou marked this pull request as ready for review July 30, 2024 07:33
@SpiritZhou SpiritZhou requested a review from a team as a code owner July 30, 2024 07:33
Signed-off-by: SpiritZhou <iammrzhouzhenghan@gmail.com>
@tomkerkhove
Copy link
Member

@wozniakjan @dttung2905 mind reviewing?

Copy link
Contributor

@dttung2905 dttung2905 left a comment

Choose a reason for hiding this comment

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

Thank you for the PR. I just have a few minor comments, mostly on the support of multiple key name in our util function

pkg/scalers/redis_scaler.go Outdated Show resolved Hide resolved
Ports []string `keda:"name=port;ports, order=triggerMetadata;resolvedEnv;authParams"`
EnableTLS bool `keda:"name=enableTLS;tls, order=triggerMetadata;authParams, optional, default=false"`
UnsafeSsl bool `keda:"name=unsafeSsl, order=triggerMetadata, optional, default=false"`
Cert string `keda:"name=Cert;cert, order=authParams"`
Copy link
Contributor

Choose a reason for hiding this comment

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

Similar question there ? Are you trying to cover all cases where user can mistakenly input a value into the manifest or such cases have been supported in the current code ? 🤔

Copy link
Member

Choose a reason for hiding this comment

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

I think multi-name keys is a good feature, although I wasn't able to find Cert (with capital C) anywhere in the original code. Maybe this is a typo?

pkg/scalers/redis_scaler.go Outdated Show resolved Hide resolved
Copy link
Member

@wozniakjan wozniakjan left a comment

Choose a reason for hiding this comment

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

lgtm, hopefully multi-named keys won't complicate the API spec generator but we will cross that bridge once we have some tooling foundation.

pkg/scalers/redis_streams_scaler.go Outdated Show resolved Hide resolved
Signed-off-by: SpiritZhou <iammrzhouzhenghan@gmail.com>
Signed-off-by: SpiritZhou <iammrzhouzhenghan@gmail.com>
@rickbrouwer
Copy link
Contributor

rickbrouwer commented Aug 20, 2024

@wozniakjan what about the usernameFromEnv and passwordFromEnv? These are mentioned in the documentation as being usable, but are no longer supported via this PR. I also have this problem with the IBM scaler and wanted to see here how it was solved. This issue will also appear by the MySQL scaler. What do you think how to solve this?

@wozniakjan
Copy link
Member

what about the usernameFromEnv and passwordFromEnv? These are mentioned in the documentation as being usable, but are no longer supported via this PR.

in this specific PR it should continue to work with usernameFromEnv, unless I'm missing something.

Username string `keda:"name=username, order=triggerMetadata;resolvedEnv;authParams"`

this contains order field tag key with value resolvedEnv (among other), and the way it's implemented internally is it appends FromEnv to the name of the parameter and then fetches key from TriggerMetadata map. It works this way because that was the convention in KEDA before #5676 and we didn't want to introduce any breaking changes with this refactor, goal is just to standardize the parsing implementations and reduce code duplication.

case ResolvedEnv:
m = sc.ResolvedEnv
key = sc.TriggerMetadata[fmt.Sprintf("%sFromEnv", key)]

It might be a bit more understandable in this unit test

func TestBasicTypedConfig(t *testing.T) {
RegisterTestingT(t)
sc := &ScalerConfig{
TriggerMetadata: map[string]string{
"stringVal": "value1",
"intVal": "1",
"boolValFromEnv": "boolVal",
"floatValFromEnv": "floatVal",
},
ResolvedEnv: map[string]string{
"boolVal": "true",
"floatVal": "1.1",
},
AuthParams: map[string]string{
"auth": "authValue",
},
}
type testStruct struct {
StringVal string `keda:"name=stringVal, order=triggerMetadata"`
IntVal int `keda:"name=intVal, order=triggerMetadata"`
BoolVal bool `keda:"name=boolVal, order=resolvedEnv"`
FloatVal float64 `keda:"name=floatVal, order=resolvedEnv"`
AuthVal string `keda:"name=auth, order=authParams"`
}
ts := testStruct{}
err := sc.TypedConfig(&ts)
Expect(err).To(BeNil())
Expect(ts.StringVal).To(Equal("value1"))
Expect(ts.IntVal).To(Equal(1))
Expect(ts.BoolVal).To(BeTrue())
Expect(ts.FloatVal).To(Equal(1.1))
Expect(ts.AuthVal).To(Equal("authValue"))
}

@rickbrouwer
Copy link
Contributor

@wozniakjan Thanks for the explanation! Then it should work fine for the rest :)

@zroubalik
Copy link
Member

zroubalik commented Aug 20, 2024

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

@SpiritZhou
Copy link
Contributor Author

SpiritZhou commented Sep 24, 2024

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

Signed-off-by: SpiritZhou <iammrzhouzhenghan@gmail.com>
@SpiritZhou
Copy link
Contributor Author

@zroubalik Could you help to review it again?

@SpiritZhou
Copy link
Contributor Author

SpiritZhou commented Sep 24, 2024

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

@zroubalik zroubalik merged commit 0b470a6 into kedacore:main Sep 26, 2024
18 of 19 checks passed
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.

6 participants