Same as ACL can limit / grant access of some users to certain command or certain pubsub channels, it could be nice that we'll also be able to grant access to certain configs and limit access to others.

Comment From: soloestoy

good idea, some configs are in normal level and some configs are in admin level, it's better to give different users different access on different configs. And more, configs could be flagged with R|W, to allow config get or set.

Comment From: madolson

I would be against this. It seems very niche to have deployments where you would have multiple administrators with different config permissions.

Comment From: oranagra

i'm not certain "multiple administrators" is right. note that some configs like maxmemory, save, and oom-score-adj are probably related to administrator and hosting, but others are more about the application, e.g. notify-keyspace-events, hash-max-listpack-entries, and maybe lua-time-limit.

if we do have some "off the shelf" libraries or applications using any of these "application" configs, then the admin has to expose CONFIG command to the application, and then they may want to protect others.

@itamarhaber do you happen to know an application, client library, or off the shelf library using some config?

Comment From: madolson

I think you highlight an important dimension, which is we have a bunch of configs which probably shouldn't be global configs: * notify-keyspace-events: A client should be able to listen to keyspace events without having to set a global config. * hash-max-listpack-entries: There should be some way to configure this on a keyspace or set of keys. * lua-time-limit: Clients should also be able to configure a timeout for their own individual lua script. A global limit can still be enforced by an administrator. This two tier exist in SQL like environments.

I think the right approach is to handle this state differently, not allow complex config management from clients.

Comment From: oranagra

these are just a few examples, there are more.

  • notify-keyspace-events - ideally you're right, client wanting to listen for these should not depend on a global config, but in practice, it has some overheads, which is why it's disabled by default and globally controlled (in principle: by the application)
  • hash-max-listpack-entries - it would have been nice to have fine grained control over these, rather than one global settings, but it would be complicated, and i'm not sure absolutely necessary. we certainly don't wanna store per-key configuration.
  • lua-time-limit, i'm not sure if thould be a timeout defined by the lua script (when it wants to yield). i think that ideally we want to completely eliminate the -BUSY error, and instead be able to postpone (rather than reject) clients we're not willing to process. this means that we can start yielding immediately.

here are a few other examples of configs that in some cases would require being set by the "application" rather than the hosting / administrator: (maybe) * lfu-decay-time * locale-collate * maxmemory-policy * proto-max-bulk-len * client-output-buffer-limit * latency-tracking-info-percentiles

bottom line is that i think we probably can't avoid having a global configs that need to be controlled by the application. maybe we should have designated s different command to control them (e.g. a TUNE command), but i'm guessing that different deployments will want to block / expose different set of configs.

Comment From: itamarhaber

@itamarhaber do you happen to know an application, client library, or off the shelf library using some config?

Sorry, I can't recall anything like that, but it reasonable to assume something like that is out there.

Comment From: madolson

bottom line is that i think we probably can't avoid having a global configs that need to be controlled by the application. maybe we should have designated s different command to control them (e.g. a TUNE command), but i'm guessing that different deployments will want to block / expose different set of configs.

I think it's more important to build out and design this first. Then maybe we can talk about if we need to add access control around it.

Comment From: soloestoy

redis-benchmark is a good example 😄 , but now it doesn't need config get save & appendonly after #11096

I wonder how users use redis-benchmark on AWS elastiCache before that, since you don't support config command.

And as I know some clients like spring-data-redis seems using config get to get some configs when start-up.