Currently, KeyDB (as with Redis) only supports binding to one of two things: individual IP addresses (specified in a list), or the entire network stack ("0.0.0.0" or without "bind" specified).
However, there are potential situations where one might want to bind to all IPs on a given interface, but might not "know" about those IPs in advance, and do not want to bind to all IPs on the system.
For instance, consider a host with 2 network interfaces. Interface A is a "public" side interface, where for whatever reason, we do not want KeyDB to listen. Interface B is a "private" side interface, where we do want KeyDB to listen. Further, due to some other solution, we have a "floating IP" which may become bound to Interface B at an arbitrary, later time, and on which we want KeyDB to also listen when the IP becomes active, without requiring a service restart. In such a situation, it would be very convenient to tell KeyDB to simply listen on "Interface B" instead of an explicit list of IPs, and instead of "0.0.0.0" which would do this but also listen on Interface A's IPs. An example of such a situation would be a Keepalived VIP IP, or some other mechanism that would do an "ip address add dev " during runtime.
It's worth noting too that newer versions of Redis support an "ignore" feature that allows "binding" to IPs that do not exist without error, but does not begin to listen on them later. KeyDB doesn't support this feature so the point is moot.
Description of the feature
Allow binding to one or more interfaces by name, instead of by IP. This should function identical to how the wildcard bind works now, but limited only to those interface(s), and not bind to any other IPs on any other interfaces.
Alternatives you've considered
Binding to all interfaces is mostly acceptable in my particular usecase, but I can see others where it is not.
Restarting KeyDB upon the allocation of new IPs is also possible, but this is suboptimal for various reasons, and would require the system allocating the IP to know about it.
Additional information
I will accept if this is impossible, but as KeyDB's stated mission is to be a more convenient/"batteries-included" version of Redis, I figure it worthwhile to ask for this feature!
The problem/use-case that the feature addresses
Currently, KeyDB (as with Redis) only supports binding to one of two things: individual IP addresses (specified in a list), or the entire network stack ("0.0.0.0" or without "bind" specified).
However, there are potential situations where one might want to bind to all IPs on a given interface, but might not "know" about those IPs in advance, and do not want to bind to all IPs on the system.
For instance, consider a host with 2 network interfaces. Interface A is a "public" side interface, where for whatever reason, we do not want KeyDB to listen. Interface B is a "private" side interface, where we do want KeyDB to listen. Further, due to some other solution, we have a "floating IP" which may become bound to Interface B at an arbitrary, later time, and on which we want KeyDB to also listen when the IP becomes active, without requiring a service restart. In such a situation, it would be very convenient to tell KeyDB to simply listen on "Interface B" instead of an explicit list of IPs, and instead of "0.0.0.0" which would do this but also listen on Interface A's IPs. An example of such a situation would be a Keepalived VIP IP, or some other mechanism that would do an "ip address add dev " during runtime.
It's worth noting too that newer versions of Redis support an "ignore" feature that allows "binding" to IPs that do not exist without error, but does not begin to listen on them later. KeyDB doesn't support this feature so the point is moot.
Description of the feature
Allow binding to one or more interfaces by name, instead of by IP. This should function identical to how the wildcard bind works now, but limited only to those interface(s), and not bind to any other IPs on any other interfaces.
Alternatives you've considered
Binding to all interfaces is mostly acceptable in my particular usecase, but I can see others where it is not.
Restarting KeyDB upon the allocation of new IPs is also possible, but this is suboptimal for various reasons, and would require the system allocating the IP to know about it.
Additional information
I will accept if this is impossible, but as KeyDB's stated mission is to be a more convenient/"batteries-included" version of Redis, I figure it worthwhile to ask for this feature!