-
Notifications
You must be signed in to change notification settings - Fork 523
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
The reply from HELLO #61
Comments
For this kind of similar commands, I prefer to keep current field and add more fields to compatible with Redis 7.2.4. |
Problem: When we change it, we make it incompatible with our own previous version. In some cases, we can have both names overlapping. That includes filenames (one filename is a symlink to the other) and INFO fields. For those, we can introduce our new fields. Then at a later major version, we can remove the old names. It's not possible with HELLO server name. |
yes, agree. Later major version, remove the old name. |
Good that we agree about the other issues. Note: For this issue (HELLO) it is not possible to have an overlapping period of two names. |
My concern is that redis might update their clients to look for this field, and error out if they see it. I suppose that is a risk for any user facing change we make. Maybe we should add a config for the compatibility layer? |
Good point @madolson. That's why I'm asking what does ElastiCache return for this field? "redis"? |
We just return redis today. I think all the major forks do too. |
OK, very good plan. Let's keep redis for now. Soon enough, let's add a compatibility switch with default ON. (Next minor milestone) |
I can confirm that there are client libraries/frameworks that expect to see the redis version. |
One of such frameworks is sidekiq. |
Would it be possible to make the value user configurable in
In later versions a user can make it say whatever they need for compatibility. Same could be done for version numbers, but that's more risky. |
Not sure why we need so much tuning, I think just a single flag which indicates what we are doing should be sufficient? I'm thinking just a flag like.
|
So, say there is a change in client libs and a new version of redis which makes whatever I can also think of scenarios where a client lib could look for one thing but maybe a user could sniff somewhere else to know it's running valkey, having tuning here would help. |
Let's not worry about future hypothetical. For the next version, top level configuration should be more than enough. It is simple and less clutter for users in config file.
It is not a problem if a user can see valkey under the hood. We are not trying to masquerade as Redis, only providing support to run existing software without much heavy lifting for users. |
True, this compatibility layer can't be a stealth mode. I don't think any client would try some command that returns an error just to check that error message contains "Redis". That would mean we can never clean up some error messages. |
Maybe like browser User Agent: (inspired by like |
This would also be a breaking change for clients. I agree about not worrying too much about that, since we can only stay truly compatible with 7.2. |
Keeping "server" => "redis" forever implies that we're also keeping "version" => "7.2.4" forever, right? We can add fields though? That can't break anyone, right? Let's consider it. It's useful to get this from HELLO so the client can infer what features are available, such as client-side tracking or future features like async blocking commands, even if those are opt-in. |
My preference is still let's not touch hello, and consider a larger change for 8.0. I think we can consider changing the server to valkey in the future. |
Yes, I'm only talking about 8.0 here. No change for 7.2. No need to make a decision about it now, but it can be good to keep in mind if we want to align terminology with INFO fields for example. |
For Valkey 8, I suggest we change it to
In addition to this, we add a
|
New config 'extended-redis-compatibility' (yes/no) default no * When yes: * Use "Redis" in the following error replies: - `-LOADING Redis is loading the dataset in memory` - `-BUSY Redis is busy`... - `-MISCONF Redis is configured to`... * Use `=== REDIS BUG REPORT` in the crash log delimiters (START and END). * The HELLO command returns `"server" => "redis"` and `"version" => "7.2.4"` (our Redis OSS compatibility version). * The INFO field for mode is called `"redis_mode"`. * When no: * Use "Valkey" instead of "Redis" in the mentioned errors and crash log delimiters. * The HELLO command returns `"server" => "valkey"` and the Valkey version for `"version"`. * The INFO field for mode is called `"server_mode"`. * Documentation added in valkey.conf: > Valkey is largely compatible with Redis OSS, apart from a few cases where > Redis OSS compatibility mode makes Valkey pretend to be Redis. Enable this > only if you have problems with tools or clients. This is a temporary > configuration added in Valkey 8.0 and is scheduled to have no effect in Valkey > 9.0 and be completely removed in Valkey 10.0. * A test case for the config is added. It is designed to fail if the config is not deprecated (has no effect) in Valkey 9 and deleted in Valkey 10. * Other test cases are adjusted to work regardless of this config. Fixes valkey-io#274 Fixes valkey-io#61 --------- Signed-off-by: Viktor Söderqvist <viktor.soderqvist@est.tech>
I think we should change it anyway, immediately in our first compatibility version. It is very low risk that any client depends on this value, since it's static.
For a better decision, what do other forks and redis-compatible services (AWS, Alibaba, ...) return for this field?
The text was updated successfully, but these errors were encountered: