V.I.C.T.O.R.I.A.

Victoria demo

Very Important Commands for Toil Optimization: Reducing Inessential Activities.

Victoria is the SRE toolbelt—a single CLI with multiple pluggable subcommands for automating any number of ‘toil’ tasks that inhibit SRE productivity.

CII Best Practices Quality gate status Maintainability rating Reliability rating Code coverage License Build status Python versions PyPI version Best practices badge

Features

  • Plugin architecture for easy extension

  • Store config for plugins in cloud storage

    • Azure Blob Storage

  • Encrypt secret config data at rest using cloud encruption provider

    • Azure Key Vault

Prerequisites

  • Python 3.6+

  • Pip

Installation

pip install -U victoria

Documentation

The documentation can be found here.

Contribution

Vulnerability reports

We prefer vulnerabilities to be reported in private so as to minimise their impact (so we can fix them before they are exploited!). To this end, please email any security vulnerability reports to ‘sre@glasswallsolutions.com‘. We would appreciate it if you use the issue template in the link below. All vulnerabilities will be acknowledged within one business day.

You can publicly report a security vulnerability here.

Pull requests

We accept pull requests! To contribute:

  1. Pick up an unassigned issue from our issue board. Assign yourself to the issue so other people know you’re working on it.

  2. Work on your code in a feature branch that’s got a descriptive name (like rework-fancy-integrator).

  3. Follow the Google style guide for Python. Every piece of code needs to be documented with Google-style docstrings. We use pylint to lint our code. We run pylint without the ‘convention’ and ‘refactor’ message classes. You can lint your code with: poetry run pylint victoria --disable="C,R". We use yapf to automatically format our code. We recommend having it format the code whenever you save.

  4. Make commits for each part of your pull request. Try not to make too many (if it’s a small issue you may only need one). We try to use the imperative mood in commit message subjects.

  5. We expect all new code to have at least 80% test coverage. This is enforced by Codecov.

  6. To run tests locally and check coverage, use: poetry run pytest tests/ --cov=victoria.

  7. When ready to merge, create a pull request from your branch into master.

  8. Make sure you link your pull request to the issue(s) it addresses.

  9. The CI build will run for your pull request. If it fails then it cannot be merged. Inspect the output, figure out why it failed, and fix the problem. The CI build will lint your code, run tests, and send coverage/code to Codecov and SonarCloud.

  10. Someone will review your pull request and suggest changes if necessary.

  11. When everything is signed off, your pull request will be merged! Congrats.