-
Notifications
You must be signed in to change notification settings - Fork 147
Labels
goPull requests that update Go codePull requests that update Go code
Description
This would enable us to write better integration/unit tests. Moreover, it encourages better abstractions and documentation.
I suggest to do this incremental, i.e. deprecate global config and refactor 1-3 non-trivial services for the start. Remaining refactor could be done ad-hoc when working on the new features/fixing stuff...
Current status:
- Oasis node global configuration (corresponding to yaml file) is set during
cmdpackage initialization (config.GlobalConfig). - Often, for
ServiceAyaml section, we have aserviceA/config.Configfield in theconfig.Configstruct, that is used also as a service configuration. - Sometimes, service configuration is dynamic or comes from multiple yaml sections (e.g. p2p service):
- Existing pattern is to dynamically parse yaml (global config) inside service package into service config.
Naive/simpler solution:
- Keep existing
serviceA/config.Configpattern for yaml config. - Every service should have explicit configuration passed into
Newconstructor:- When 1:1 mapping between yaml config and service config just pass config from 1..
- Otherwise:
- Create additional struct for config (this is how is done now).
- What changes is that parsing it from yaml (if not 1:1) should be moved into
configpackage under[service].go.
- As a consequence config package will import all services (is the case already).
Ideal Solution
Every service should have serviceA.Config and it should not know anything about node and yaml.
On the other hand, we should configure the service in yaml ( config.Config) by:
- Referencing
serviceA.Configdirectly if there is1:1mapping between yaml section for the service. - Defining a new struct for the yaml section, together with a helper that transforms yaml to corresponding service config.
Metadata
Metadata
Assignees
Labels
goPull requests that update Go codePull requests that update Go code