Articles from amoralej

Newbie in RDO: one size doesn't fit all

As a new contributor to the RDO project, one of my first tasks was to understand what is actually being produced by the project. According to RDO faq, the main goal is to maintain a freely-available, community-supported distribution of OpenStack based on RPM packages able to run Red Hat Enterprise Linux, CentOS, Fedora, and their derivatives. But the RDO community is diverse and different use patterns...

Read More »

RDO CI promotion pipelines in a nutshell

One of the key goals in RDO is to provide a set of well tested and up-to-date repositories that can be smoothly used by our users:

  • Operators deploying OpenStack with any of the available tools.
  • Upstream projects using RDO repos to develop and test their patches, as OpenStack puppet modules, TripleO or kolla.

To include new patches in RDO packages as soon as possible, in RDO Trunk repos we...

Read More »

Newbie in RDO (2): RDO Trunk from a bird's eye view

Time goes fast as a RDO newbie and once I understood what the RDO Trunk and CloudSIG repos provide (read my previous post if you still have doubts), my next goal was to have a clear high-level perspective of the entire delivery workflow followed in the project.

Although there is a lot of detailed and great information in different sources (see More info at the end of the post), it may be useful...

Read More »

The journey of a new OpenStack service in RDO

When new contributors join RDO, they ask for recommendations about how to add new services and help RDO users to adopt it. This post is not a official policy document nor a detailed description about how to carry out some activities, but provides some high level recommendations to newcomers based on what I have learned and observed in the last year working in RDO.

Note that you are not required...

Read More »

Chasing the trunk, but not too fast

As explained in a previous post, in RDO Trunk repositories we try to provide packages for new commits in OpenStack projects as soon as possible after they are merged upstream. This has a number of advantages:

  • It allows packagers to identify packaging issues just after introduced.
  • For project developers, their changes are tested in non-devstack environments, so test coverage is extended.
  • ...
Read More »