Pablo Iranzo Gómez's blog

A bunch of unrelated data

oct 16, 2018

Contributing to OSP upstream a.k.a. Peer Review

Table of contents

  1. Introduction
  2. Upstream workflow
    1. Peer review
    2. CI tests (Verified +1)
    3. Code Review+2
    4. Workflow+1
    5. Cannot merge, please rebase
  3. How do we do it with Citellus?


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.

The last command executed (git-review) on the submit sequence (in the prior article) will effectively submit the patch to the defined git review service (git-review -s does the required setup process) and will print an URL that can be used to access the review.

Each project might have a different review platform, but usually for OSP it's while for other projects it can be,, etc (this is defined in .gitreview file in the repository).

A sample .gitreview file looks like:


For a review example, we'll use one from gerrithub from Citellus project:

Here, we can see that we're on review 380646 and that's the link that allows us to check the changes submitted (the one printed when executing git-review).

CI tests (Verified +1)

Once a review has been submitted, usually the bots are the first ones to pick them and run the defined unit testing on the new changes, to ensure that it doesn't break anything (based on what is defined to be tested).

This is a critical point as:

  • Tests need to be defined if new code is added or modified to ensure that later updates doesn't break this new code without someone being aware.
  • Infrastructure should be able to test it (for example you might need some specific hardware to test a card or network configuration)
  • Environment should be sane so that prior runs doesn't affect the validation.

OSP CI can be checked at 'Zuul' where you can 'input' the number for your review and see how the different bots are running CI tests on it or if it's still queued.

If everything is OK, the bot will 'vote' your change as Verified +1 allowing others to see that it should not break anything based on the tests performed

In the case of OSP, there's also third-party CI's that can validate other changes by third party systems. For some of them, the votes are counting towards or against the proposed change, for others it's just a comment to take into account.

Even if sometimes you know that your code is right, there's a failure because of the infrastructure, in those cases, writing a new comment saying recheck, will schedule a new CI test run.

This is common usually during busy periods when it's harder for the scheduler to get available resources for the review validation. Also, sometimes there are errors in the configuration of CI that must be fixed in order to validate those changes.

Note: you can run some of the tests on your system to validate faster if you've issues by running tox this will setup virtual environment for tests to be run so it's easier to catch issues before upstream CI does (so it's always a good idea to run tox even before submitting the review with git-review to detect early errors).

This is however not always possible as some changes include requirements like testing upgrades, full environment deployments, etc that cannot be done without the required preparation steps or even the infrastructure.

Code Review+2

This is probably the 'longest' process, it requires peers to be added as 'reviewer' (you can get an idea on the names based on other reviews submitted for the same component) or they will pick up new reviews as the pop un on notification channels or pending queues.

On this, you must prepare mentally for everything... developers could suggest to use a different approach, or highlight other problems or just do some small nit comments to fixes like formating, spacing, var naming, etc.

After each comment/change suggested, repeat the workflow for submitting a new patchset, but make sure you're using the same review id (that's by keeping the commit id that is appended): this allows the Code Review platform to identify this change as an update to a prior one, and allow you for example to compare changes across versions, etc. (and also notify the prior reviewers of new changes).

Once reviewers are OK with your code, and with some 'Core' developers also agreeing, you'll see some voting happening (-2..+2) meaning they like the change in its actual form or not.

Once you get Code Review +2 and with the prior Verified +1 you're almost ready to get the change merged.


Ok, last step is to have someone with Workflow permissions to give a +1, this will 'seal' the change saying that everything is ok (as it had CR+2 and Verified+1) and change is valid...

This vote will trigger another build by CI, and when finished, the change will be merged into the code upstream, congratulations!

Cannot merge, please rebase

Sometimes, your change is doing changes on the same files that other programmers did on the code, so there's no way to automatically 'rebase' the change, in this case the bad news is that you need to:

git checkout master # to change to master branch
git pull # to push latest upstream changes
git checkout yourbranch # to get back to your change branch
git rebase master # to apply your changes on top of current master

After this step, it might be required to manually fix the code to solve the conflicts and follow instructions given by git to mark them as reviewed.

Once it's done, remember to do like with any patchset you submited afterwards:

git commit --amend # to commit the new changes on the same commit Id you used
git-review # to upload a new version of the patchset

This will start over the progress, but will, once completed to get the change merged.

How do we do it with Citellus?

In Citellus we've replicated more or less what we've upstream... even the use of tox.

Citellus does use (free service that hooks on github and allows to do PR)

We've setup a machine that runs Jenkins to do 'CI' on the tests we've defined (mostly for python wrapper and some tests) and what effectively does is to run tox, and also, we do use free Tier to repeat the same on other platform.

Tox is a tool that allows to define several commands that are executed inside python virtual environments, so without touching your system libraries, it can get installed new ones or removed just for the boundaries of that test, helping into running:

  • pep8 (python formating compliance)
  • py27 (python 2.7 environment test)
  • py35 (python 3.5 environment test)

The py tests are just to validate the code can run on both base python versions, and what they do is to run the defined unit testing scripts under each interpreter to validate.

For local test, you can run tox and it will go trough the different tests defined and report status... if everything is ok, it should be possible that your new code review passes also CI.

Jenkins will do the +1 on verified and 'core' reviewers will give +2 and 'merge' the change once validated.

Hope you enjoy!


Click to read and post comments

sep 25, 2018

Peru for syncing specific git repo files

Peru a repo syncer

Some projects upstream bind together lot of files which might not be of interest, but still the conveniency of a git pull to get latest updates, makes you to download the whole repo for just a bunch of files or folders.

For example, this website uses Pelican to generate the webpages out of markdown files. Pelican does have a rich set of plugins but all of them are in the same folder in the git checkout.

Here, is where peru comes in to play. Peru (hosted at comes handy at this task.

You can install peru from pipsi:

pipsi install peru

And will provide you a commandline tool that uses a yaml file for definition of repositories, like the one I do use here:

    # The dircolors file just goes at the root of our project.
    sitemap: plugins/
    better_codeblock_line_numbering: plugins/
    better_figures_and_images: plugins/
    yuicompressor: plugins/

git module sitemap:
    pick: sitemap
    rev: ead70548ce2c78ed999273e265e3ebe13b747d83

git module yuicompressor:
    pick: yuicompressor
    rev: ead70548ce2c78ed999273e265e3ebe13b747d83

git module better_figures_and_images:
    pick: better_figures_and_images
    rev: ead70548ce2c78ed999273e265e3ebe13b747d83

git module better_codeblock_line_numbering:
    pick: better_codeblock_line_numbering
    rev: ead70548ce2c78ed999273e265e3ebe13b747d83

In this way, peru sync will download from the provided repos the specified folder into the destination indicated, allowing you to integrate "other repo's files" in your own workflow.

For example, if you want to use citellus repo at one specific point in time, to be integrated in your code, you could use:

    citellus: ./

git module citellus:
    pick: citellusclient/plugins/
    rev: 1ee1c6a36f51e8a7c809d5162004fb57ee99b168

This will checkout citellus repo at one specific point in time and merge in your current folder.



Click to read and post comments

jun 07, 2018

may 13, 2018

SuperSec 2018!

Presentation at SuperSec 2018!

I've got a slot at SuperSec 2018 ( Congress on secure software development, happening in Almería, Spain on the weekend on 12-13 May.

I'll be presenting on 13th may at 10:50, and the slide deck to be used is at and I'll be updating this once I get the recording URL.

Some data about the event:

About the topics, the main focus was security on software from design phase to production and maintenance.

Some of the presentations insisted on the costs not only for your brand, reputation or business damage, but also on the actual cost of fixing issues later on vs doing a secure development.

For the secure development approach, where most of the bugs are introduced and can be fixed for cheap, some tools were presented that help to early detect known coding mistakes, hilighting them in automated, and later, working on static code analysis and code review.

It was also interesting to see the EU focus via FOSSA-2 project to promote Open Source and hear about legal implications and intended roadmap for security in software, both for Spain and EU.

Common Criteria was also one of the topics as well as the code audits, penetration testing, etc (with over 20 slots you can imagine :) )

On our side, we were presenting about how Citellus can help in detecting current or future issues that affect your environment and how easily it can be extended to cover your use cases while contributing it back to community.

Of course we were also hilighting how collaboration got Citellus enhanced with feedback from RDO Project users to cover not only RHEL6 and RHEL7 but also Fedora, CentOS and other distributions via more generic tests and functios that covers them.


PD: Hilighted in Citellus blog at

Click to read and post comments

ene 27, 2018 2018!

Presentation at 2018!

As hilighted in the prior edition of the 'What's new', we got a slot for 2018.

During that slot, my colleagues Martin, Pablo and myself were presenting on the history and basics of Citellus and how it helps on debugging issues and providing faster analysis of already known ones.

It is possible to watch the recording at and the slides used at:

Hope you enjoy it!

Click to read and post comments
Next → Page 1 of 2