Hudl is "Baked" In

[citruspi]

While not a major issue, it's something that I'd like to make note off. Hudl's requirements are baked in to a certain extent. All the defaults, from the default data volume size for a MongoDB data node to the hosted zones used to build node hostnames are Hudl specific.

If someone wanted to use it outside of Hudl, they would have to modify all the defaults, which would be a painful experience. They would then need to keep their fork up to date, merging in new changes.

I'd like to move to a configuration file system where defaults are read in from a configuration file and can be overridden through the arguments that are passed in to different functions.

Not only would this enable people outside of Hudl to use it without a significant amount of friction, but it would also mean that even within Hudl, modifying defaults, or values that can't be overridden with arguments, wouldn't involve digging through the source code to make changes.

@jamiegs mentioned that if default values weren't baked in, and were separate from the source code, we could keep the values consistent across users by allowing users to specify a configuration file accessible over HTTP in addition to on the file system. So we could keep a common Hudl-centric configuration on Amazon S3 for employees to use.

Of course, if we make this change around the same time that we turn the project into an online service, this wouldn't be required. Everyone would interact with a single instance which would have a consistent configuration file. Modifying the configuration would require just modifying that one instance, and we wouldn't need to worry about keeping developer machines consistent.