OpenStack

OSP Director OSP Director (or upstream TripleO) is a life-cycle manager for OpenStack based on the idea of using ‘OpenStack’ to deploy ‘OpenStack’. To do so, it creates a management ‘Undercloud’, that is configured and prepared for later deploying an ‘overcloud’ which is the one that will later run the workloads. TripleO/Director, also automates the inspection of hosts and tagging to the roles they will perform later in the ‘overcloud’ setup, such as ‘controller’, ‘compute’, ‘storage’, or even mixed roles via composable-roles support. ...

Introduction In the article “Contributing to OpenStack” we did cover on how to prepare accounts and prepare your changes for submission upstream (and even how to find low hanging fruits to start contributing). Here, we’ll cover what happens behind the scene to get change published. Upstream workflow Peer review Upstream contributions to OSP and other projects are based on Peer Review, that means that once a new set of code has been submitted, several steps for validation are required/happen before having it implemented. ...

Citellus: Detecting common pitfalls of deployments https://github.com/citellusorg/citellus Recording at https://www.youtube.com/watch?v=SDzzqrUdn5A What is Citellus? Citellus is a framework populated by community-contributed scripts that automate detecting problems, including configuration issues, conflicts with package versions, and more. History: how did was it started? The tool, started by Robin Černín after a long weekend shift checking one and over again several sosreports for the same data on different hosts. It started with some tests + shell wrapper, and was added a python wrapper by Pablo Iranzo to bring in more powerful features. ...

Why? While working on Citellus and Magui it soon became evident that Unit testing for validating the changes was a requirement. Initially, using a .travis.yml file contained in the repo and the free service provided by https://travis-ci.org we soon got https://github.com repo providing information about if the builds succeeded or not. When it was decided to move to https://gerrithub.io to work in a more similar way to what is being done in upstream, we improved on the code commenting (peer review), but we lost the ability to run the tests in an automated way until the change was merged into github. ...

Background Citellus allows to check a sosreport against known problems identified on the provided tests. This approach is easy to implement and easy to test but has limitations when a problem can span across several hosts and only the problem reveals itself when a general analysis is performed. Magui tries to solve that by running the analysis functions inside citellus across a set of sosreports, unifying the data obtained per citellus plugin. ...