Closed joe94 closed 4 years ago
My understanding of the goal of the documentation of the yaml is that when someone installs the rpm, it contains the yaml with this documentation so they automatically get this. I'm not a big fan of splitting the documentation up into separate yamls as I think that increases confusion even if it decreases duplication. Also, there are some configuration values that are used by multiple services but not all of them so there aren't just two buckets - "universal" and "server specific".
Moving blocks of configuration around in the current files sounds fine to me; the current system I'm aware of is the same order of general xmidt stuff at the top and server specific stuff at the bottom. Flipping it seems fine. Personally I just want to have an order I expect.
@kristinaspring that's good you brought up RPMs to the picture ...
Considering that, I'm leaning to only implement the flipping orders portion then.
And just FYI: I was taking a the perspective of someone taking the opensource project and creating the comcast specific deployment configs for the new themis as an example.
@johnabass, thoughts?
It might be better to continue the current system until we get learn more about the experience of teams that use our product from the opensource.
Today, each server repo provides a sample configuration file with useful comments on each config. While this works, it creates a lot of repeated effort and takes away focus from configuration values that are specific to the service.
One approach to
reduce repeated effort: is having a guide to configuration values that are common across the different XMIDT servers. This could take the form of a yaml file or wiki page with all the common config values and sufficiently thorough explanation similar to the yaml config files we already have in each server package.
regain focus: transform the existing config files in each server repo by placing server-specific values with comments at the top and placing all common values (already explained in the common guide) at the bottom