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

add support for multiple redis list types in redis list scaler #1006

Closed
wants to merge 1 commit into from
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 22 additions & 1 deletion pkg/scalers/redis_scaler.go
Original file line number Diff line number Diff line change
Expand Up @@ -197,9 +197,30 @@ func getRedisListLength(ctx context.Context, address string, password string, li
}

client := redis.NewClient(options)
var listType *redis.StatusCmd

cmd := client.LLen(listName)
listType = client.Type(listName)
Copy link
Member

Choose a reason for hiding this comment

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

Not sure if list name is appropriate here

Copy link
Contributor Author

Choose a reason for hiding this comment

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

any other suggestions ?

if listType.Err() != nil {
return -1, listType.Err()
}

var cmd *redis.IntCmd
switch listType.Val() {
Copy link
Member

Choose a reason for hiding this comment

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

Do we just pull from the correct type or does the type have to be configured?

Copy link
Contributor

Choose a reason for hiding this comment

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

The way I'm reading the change, and I'm no redis expert btw, is that the particular list we're trying to scale on could have different types that require a different call on the client. I think the approach looks fine to me.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Do we just pull from the correct type or does the type have to be configured?

it may be configured by the user but we sill will have to do switch casing on it for different api call to redis, so this approach is more flexible to the user

Copy link
Member

Choose a reason for hiding this comment

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

If it's a type of list, then it's ok for me but if it's a different type of entity I would make it configurable on what people want to get

Copy link
Contributor Author

Choose a reason for hiding this comment

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

lets call it collection instead of a list, and you have different type of collections(list, set, map, etc ..) that all have "name" and "length" and those are the only parameters i would want the user to configure

case "list":
cmd = client.LLen(listName)
case "set":
cmd = client.SCard(listName)
case "hash":
cmd = client.HLen(listName)
case "zset":
cmd = client.ZCard(listName)
default:
cmd = nil
}

if cmd == nil {
return -1, fmt.Errorf("list must be of type:list,set,hash,zset but was %s", listType.Val())
}
if cmd.Err() != nil {
return -1, cmd.Err()
}
Expand Down