Did you read the rules to contributing in CONTRIBUTING.md
Yes
What are you trying to accomplish?
Add a CLI base, init config, config logic for CLI, and logger stuff
How are you accomplishing it?
I chose zerolog for the logger because its performant and has a nice builder API which i really like
I split up the config into 2 major sections
Init
Shared
Init config is for unmarshaling the config file, env vars, and flags and for dealing with system init logic like initializing the logger nicely and having a nice log level.
Shared config is a bit more complicated. As there are things that NEED to be shared between the major systems( Currently planned as tun router, sonar(peer discovery system), and maybe a peer listener(that may not be needed depending on how we bind the port to the interface). The shared config needs to be lean(so we arent sharing too much memory or something that doesnt need to be shared) and safe. for safety I put a read-write mutex because were doing a bunch of reads and little writes. The actual implementation isnt finished but Itll generally work like that.
We may find a better pattern for sharing peer list and everything else that is needed in the share config. A better pattern could be a message system that shares copies of the config and gets updates through channels. Something kinda similar to the observer pattern.
For now, the general shared config pattern is fine.
Is there anything reviewers should know?
zerolog in our use case is thread safe but normally its not guaranteed to be thread safe
Shared config isnt finished but represents the base of the config
Read my commit messages for more info
If needed, did you change documentation(README.md, ARCHITECTURE.md, etc) to reflect your changes?
[x] Is it safe to rollback this change if anything goes wrong?
yeah but idk why you would
Did you read the rules to contributing in
CONTRIBUTING.mdYes
What are you trying to accomplish?
Add a CLI base, init config, config logic for CLI, and logger stuff
How are you accomplishing it?
I chose zerolog for the logger because its performant and has a nice builder API which i really like
I split up the config into 2 major sections
Init config is for unmarshaling the config file, env vars, and flags and for dealing with system init logic like initializing the logger nicely and having a nice log level.
Shared config is a bit more complicated. As there are things that NEED to be shared between the major systems( Currently planned as tun router, sonar(peer discovery system), and maybe a peer listener(that may not be needed depending on how we bind the port to the interface). The shared config needs to be lean(so we arent sharing too much memory or something that doesnt need to be shared) and safe. for safety I put a read-write mutex because were doing a bunch of reads and little writes. The actual implementation isnt finished but Itll generally work like that.
We may find a better pattern for sharing peer list and everything else that is needed in the share config. A better pattern could be a message system that shares copies of the config and gets updates through channels. Something kinda similar to the observer pattern.
For now, the general shared config pattern is fine.
Is there anything reviewers should know?
zerolog in our use case is thread safe but normally its not guaranteed to be thread safe
Shared config isnt finished but represents the base of the config
Read my commit messages for more info
If needed, did you change documentation(
README.md,ARCHITECTURE.md, etc) to reflect your changes?