-
Notifications
You must be signed in to change notification settings - Fork 265
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
make database config optional #322
Comments
we don't want to use DEFAULT_UNIXSOCKET anymore, later we will always have database config file which is built in images by default. Everything related to DB will be read from the config file in future. database config doesn't exist is a invalid case in furture. |
Thanks for your prompt response. |
@ishidawataru Could you give a use case? The new feature should be backward-compatible by design. |
@qiluo-msft Actually, I was suggesting to maintain the backward compatibility which was broken by #319. Before the PR, I could use this library without |
@ishidawataru Yes, we are considering this. I am asking for a true use case so we could improve the implementation for backward compatibility. Do you have some sample code? |
I'm not using the official SONiC container image. I'm developing a minimalistic SONiC package that could be installed on any Linux distribution. PoC code here. https://github.com/ishidawataru/usonic |
Offline discussed with @ishidawataru, this issue is a feature requirement. Use case:
Currently swss-common library's downstream modules are using dbName string to access a Redis database, we need to implement a mapping from dbName to dbID (integer) without a configuration file. |
Today database_config.json will be placed into the correct location when swsscommom deb pkg is installed. The default context is the same single dB mode as earlier(port, socket are the same as before). All new Lib API will read this file automatically and old API still works since it is not removed from swsscomm lib. |
I believe the config file installation is not there when the issue is filed. Later we add this feature. |
If the library can't make the configuration file optional, can it have an option to change the location of the configuration file on runtime by using an env variable? Also, it'd be nice if we can control which method, network or unix domain socket to use to access the Redis in this configuration file. ( maybe I should create a new issue for this? ) |
@ishidawataru The environment support is not available. But if you want to runtime change path, you could call You mean TCP/unixsocket by "method"? It is currently part of code, and the config file has both. The TCP port and unixsocket path could be configured in this file. Let me know if current implementation could cover all your requirement. |
@qiluo-msft Is it acceptable if I submit a PR to make this configurable by using an env variable?
Yes. In my understanding, currently, the application is choosing which to use TCP or Unix socket to access the database. Can we force the application to use one method ( for example TCP only ) by using the configuration file? By supporting this, we can have remote Redis instance which can't be accessed via Unix socket. |
Offline discussed with @dzhangalibaba @ishidawataru
We are agree on Item 1. @ishidawataru will work on it. |
Thie PR made the existence of the database config mandatory.
To preserve previous behavior, I think it's better to make the config optional.
Is it possible to change the implementation to use DEFAULT_UNIXSOCKET if the database config doesn't exist?
The text was updated successfully, but these errors were encountered: