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

Enable service configuration by using configuration files #435

Open
ghost opened this issue Oct 31, 2018 · 12 comments · Fixed by #1223
Open

Enable service configuration by using configuration files #435

ghost opened this issue Oct 31, 2018 · 12 comments · Fixed by #1223

Comments

@ghost
Copy link

ghost commented Oct 31, 2018

FEATURE REQUEST

  1. Is there an open issue addressing this request? If it does, please add a "+1" reaction to the
    existing issue, otherwise proceed to step 2.

  2. Describe the feature you are requesting, as well as the possible use case(s) for it.

Currently, services are configured by setting environment variables, or by defaults if variables are not set.
It would be nice to be able to supply a configuration file to the service as well.

  1. Indicate the importance of this feature to you (must-have, should-have, nice-to-have).

This is a nice to have feature, especially in cases when someone runs a service outside a docker container.

@ghost
Copy link
Author

ghost commented Oct 31, 2018

I would advise checking viper, since it can read environment variables and also read configuration files in several formats

@ghost ghost added the later label Oct 31, 2018
@drasko
Copy link
Contributor

drasko commented Oct 31, 2018

Agreed - Viper looks like a nice tool for the job.

@drasko
Copy link
Contributor

drasko commented Jul 29, 2019

I am not sure that we need this one. Config files are more difficult to distribute (although not much more), and we have nice solution no with .env.

@nmarcetic @anovakovic01 opinions?

@drasko
Copy link
Contributor

drasko commented Sep 25, 2019

Also - if we leave both solutions - ENV and .config files if present (or used with a --config switch), this might be the best option.

@chombium
Copy link
Collaborator

@mainflux/contributors do we really need two ways for configuration? IMHO we should have one and only one way for configuration. I personally don't like systems where a same functionality can be achieved in many different ways as it confuses the users and it makes the implementation more complex

@drasko
Copy link
Contributor

drasko commented Sep 30, 2019

@chombium my opinion is that config via ENV variables is the best approach, but it would not bother me if config files and command line switches exist as an alternative.

I just think that this is really not necessary and makes things harder to maintain.

@manuio
Copy link
Contributor

manuio commented Oct 1, 2019

@drasko We solved the problem for docker but natively it still complicated to setup the system (if you're not using default one, of course) because there are many duplicated variables all around the code.
How hard it would be to remove all definitions from main.go and copy the values from the same file used for Docker .env ?

@nmarcetic
Copy link
Collaborator

I agree with @srados I would use Viper to read config files and/or ENV var. So would support bought config + env, it would be great!

@manuio
Copy link
Contributor

manuio commented Sep 7, 2020

Reopening this one to finish services implementation

@manuio manuio reopened this Sep 7, 2020
@cyber-goka
Copy link

cyber-goka commented Feb 24, 2023

idk if it is relevant but in microservices architecture, it is very common to use discovery + config servers such as a consul, it can even store passwords if integrated with the vault. provisioning in k8s, docker-compose will be easier. also can implement service discovery with consul

@drasko
Copy link
Contributor

drasko commented Feb 24, 2023

@cyber-goka we use k8s for professional deployments and docker-compose for dev, so no problems with service discovery.

@cyber-goka
Copy link

got it, thanks

@dborovcanin dborovcanin modified the milestones: 1.0.0, S5 May 15, 2024
@dborovcanin dborovcanin moved this to Todo in SuperMQ May 15, 2024
@dborovcanin dborovcanin moved this from Todo to Backlog in SuperMQ May 15, 2024
@dborovcanin dborovcanin moved this from Backlog to In Progress in SuperMQ Jun 12, 2024
@dborovcanin dborovcanin modified the milestones: S5, 0.15.0 Jun 12, 2024
@dborovcanin dborovcanin moved this from In Progress to 🧪 Review and testing in progress in SuperMQ Jun 12, 2024
@dborovcanin dborovcanin moved this from 🩺 Review and testing to ⛏ Backlog in SuperMQ Jun 26, 2024
@dborovcanin dborovcanin moved this from ⛏ Backlog to 🚧 In Progress in SuperMQ Jul 24, 2024
@dborovcanin dborovcanin moved this from 🚧 In Progress to ⛏ Backlog in SuperMQ Jul 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: 🛑 Blocked
Development

Successfully merging a pull request may close this issue.

7 participants