Building your own version of something is surely self indulgent wheel reinventing, but that’s what I’m currently doing with distributed configuration management

Building your own version of something is surely self indulgent wheel reinventing, but that’s what I’m currently doing with distributed configuration management. It’s certainly been helpful in terms of understanding the boundaries between parts of the system, as this post also describes. The desire to auto configure everything is strong — one day you’ll have a VLAN hard coded into the config, but the next day you’ll be trying to programmatically distribute VLAN ids based on function instead. The day after that VLANs themselves are a artifact generated from a higher level separation in your human readable config. What was once a list of hosts with an attached VLAN id is now a group of hosts with a declared function that just happens to be programmatically assigned a VLAN id, but only as an implementation detail. The same happens with IP address management — your root configuration moves closer and closer to being a document describing what you want to do, and less about how to go about doing it (which is implemented in your custom augmentations to the engine instead.) When you can justify it as an exercise in understanding a system, and you have time for it, building your own tool chain is incredibly rewarding.