Architectural Changes and why we did them

Architectural Changes

As of Spring 2021 we moved from Salt to Ansible. The current plan (subject to change as we learn more about Ansible), is to have one central Inventory file with each server in it. Since us introducing new servers is rare we can have this file be static with the network crew manually adding new entries as needed. Each of our docker services should have an Ansible role defined inside that can be included in a main playbook to update all of the servers at once.

If future network coordinators and the house agree in the future to eschew owning our own servers, and run on the cloud instead, then the recommended tool for automating the builds for a system like that would be Terraform.

Why we did them

Ultimately the lesson to be learned is: PAY YOUR TECHNICAL DEBT.

Our old saltstack architecture worked well when it was made. The problems come when you have fixes on top of fixes. There was a large amount of Python2 written by a member who no longer lived in the house and who left no comments. The version of saltstack that this ran on was quite old, enough to the point that as of the moment there have been over 36k commits between then and the current most recent version. This led to only being able to deploy via Ubuntu or a virtual machine running Ubuntu. So going forward I hope everyone who contributes to the network can remember one thing: keep it simple.

As to why we chose Ansible, there are a few main reasons:

• Ansible uses python for scripting when needed, which will be known by many crewmembers who have already taken CS61A.
• Ansible is already closer by default to how we were using saltstack in the first place
  • The Ansible default is to be ran on a local machine and ssh into all of the servers to run commands and put them into the desired final state
  • The saltstack default is to have some always running master that minions connect to and are updated from. While we currently run saltstack in a fashion closer to Ansible with salt-ssh this seems to be trying to fit a saltstack shaped peg into an Ansible shaped hole.
• The documentation for Ansible is quite good, and generally newbie friendly

Any future house members may decide that Ansible isn't the way to go long term either. Thats fine. I just hope that knowing what went into choosing Ansible for us can help you use better tools too.