This repository contains tools to help maintain our infrastructure.
If you want to get quick access to operations related links, you are invited to use the Operations start page as a start page for your browser.
A static page linking to various tools for infrastructure work.
Access the Operations start page
Infrastructure work items are hosted in this repository issue tracker, you can visualize their status and how they relate to each other.
Issues are displayed in a 4 columns table, each column describe the issue’s status:
Here is a screenshot of how it looks like.
Each column content can be hidden to reduce visual noise by clicking on the minus symbol at the top
1, 2, 3, 4, 5
: Columns defines where the task is at (working, done, etc.)1
: is where EVERY new issues goes. Waiting to be prioritized.2
: is where we put tasks that we decided we set for later.3, 4, 5
: Columns represent tasks that are planned to be worked on during the current iteration4
: Task on top has more priority than the one below. This is most true in the case of the "Working" column.6
: Shows the picture of the person who was assigned to the task7
: Shows the GitHub repo issue number. You can click on it to get to the issue on GitHub8
: Once the task is in the "Done" column we have to close it. Note that we could also do "comment and close" directly in GitHub.
Which would make a "Archive" button like we see at 99
: To hide from view the task. Its useful so we can visualize what’s been done so far and discuss10
: Each task can have labels with color codes11
: We can link other GitHub repos (e.g. the home page repo) to the ops dashboard. 12
: if a task cannot be done, we can flag it as "blocked", see the "x" on the side of the cardThe main component of WebPlatform infrastructure is a VM called salt
answering from salt.webplatform.org
which is used as a server to launch every maintenance task and also as a SSH jump box.
While the salt master is the most important component of WebPlatform’s infrastructure, the server is made in a way that we lose the server at any time and still be able to build a new one from scratch.
In order to achieve this, we scattered in specialized git repositories every bits and pieces that runs the system.
For more detail, refer to The Salt Master document in WebPlatform’s docs pages.
The salt-master folder of this repository contains the scripts to create it.
Our salt-states scripts supports deployment of the site without taking into account the live site.
While it spossible to work on any component of the site from the salt master, its preferable to be able to work on configuration scripts without any possibility to impact the live site.
Ideally, we should do development work either a staging environment (i.e. webplatformstaging.org) on an OpenStack project, or from a Vagrant VM.
The vagrant workbench AND vagrant minions allows you work on salt states within a set of Vagrant VMs.
With both repositories you get everything you need to have your own salt master, and an utility to add minions by editing entries in minions.yml.
Review the vagrant-workbench and vagrant-minions sub-projects.