RDO Community News

See also blogs.rdoproject.org

Blog posts last week

With OpenStack Summit last week, we have a lot of summit-focused blog posts today, and expect more to come in the next few days.

Attending OpenStack Summit Ocata by Julien Danjou

For the last time in 2016, I flew out to the OpenStack Summit in Barcelona, where I had the chance to meet (again) a lot of my fellow OpenStack contributors there.

Read more at http://tm3.org/bu

OpenStack Summit, Barcelona, 2 of n by rbowen

Tuesday, the first day of the main event, was, as always, very busy. I spent most of the day working the Red Hat booth. We started at 10 setting up, and the mob came in around 10:45.

Read more at http://tm3.org/bx

OpenStack Summit, Barcelona, 1 of n by rbowen

I have the best intentions of blogging every day of an event. But every day is always so full, from morning until the time I drop into bed exhausted.

Read more at http://tm3.org/by

TripleO composable/custom roles by Steve Hardy

This is a follow-up to my previous post outlining the new composable services interfaces , which covered the basics of the new for Newton composable services model.

Read more at http://tm3.org/bo

Integrating Red Hat OpenStack 9 Cinder Service With Multiple External Red Hat Ceph Storage Clusters by Keith Schincke

This post describes how to manually integrate Red Hat OpenStack 9 (RHOSP9) Cinder service with multiple pre-existing external Red Hat Ceph Storage 2 (RHCS2) clusters. The final configuration goals are to have Cinder configuration with multiple storage backends and support …

Read more at http://tm3.org/bz

On communities: Sometimes it's better to over-communicate by Flavio Percoco

Communities, regardless of their size, rely mainly on the communication there is between their members to operate. The existing processes, the current discussions, and the future growth depend heavily on how well the communication throughout the community has been established. The channels used for these conversations play a critical role in the health of the communication (and the community) as well.

Read more at http://tm3.org/c0

Full Stack Automation with Ansible and OpenStack by Marcos Garcia - Principal Technical Marketing Manager

Ansible offers great flexibility. Because of this the community has figured out many useful ways to leverage Ansible modules and playbook structures to automate frequent operations on multiple layers, including using it with OpenStack.

Read more at http://tm3.org/bs

View article »

Next week in Barcelona

Join us next week in Barcelona for OpenStack Summit. We'll be gathering from around the world to celebrate the Newton release, and plan for the Ocata cycle.

RDO will have a table in the Red Hat booth, where we'll be answering your questions about RDO. And we'll have ducks, as usual.


On Tuesday evening, join us for an evening with RDO and Ceph, with technical presentations about both projects, as well as drinks and light snacks.

And, throughout the week, RDO enthusiasts are giving a wide variety of talks about all things OpenStack.

If you're using RDO, please stop by and tell us about it. We'd love to meet you, and find out what we, as a project, can do better for you and your organization.

See you in Barcelona!

View article »

RDO blog posts this week

Here's what RDO enthusiasts have been blogging about in the last few days.

RDO Newton Released by Rich Bowen

The RDO community is pleased to announce the general availability of the RDO build for OpenStack Newton for RPM-based distributions, CentOS Linux 7 and Red Hat Enterprise Linux. RDO is suitable for building private, public, and hybrid clouds. Newton is the 14th release from the OpenStack project, which is the work of more than 2700 contributors from around the world (source).

Read more at http://tm3.org/bm

How to run Rally on Packstack environment by mkopec

Rally is a benchmarking tool that automates and unifies multi-node OpenStack deployment, cloud verification, benchmarking & profiling. For OpenStack deployment I used packstack tool.

Read more at http://tm3.org/bn

TripleO Composable Services 101 by Steve Hardy

Over the newton cycle, we've been working very hard on a major refactor of our heat templates and puppet manifiests, such that a much more granular and flexible "Composable Services" pattern is followed throughout our implementation.It's been a lot of work, but it's been a frequently requested feature for some time, so I'm excited to be in a position to say it's complete for Newton (kudos to everyone involved in making that happen!) :)This post aims to provide an introduction to this work, an overview of how it works under the hood, some simple usage examples and a roadmap for some related follow-on work.

Read more at http://tm3.org/8b

TripleO composable/custom roles by Steve Hardy

This is a follow-up to my previous post outlining the new composable services interfaces , which covered the basics of the new for Newton composable services model.The final piece of the composability model we've been developing this cycle is the ability to deploy user-defined custom roles, in addition to (or even instead of) the built in TripleO roles (where a role is a group of servers, e.g "Controller", which runs some combination of services).What follows is an overview of this new functionality, the primary interfaces, and some usage examples and a summary of future planned work.

Read more at http://tm3.org/bo

Ceph/RDO meetup in Barcelona at OpenStack Summit by Rich Bowen

If you'll be in Barcelona later this month for OpenStack Summit, join us for an evening with RDO and Ceph.

Read more at http://tm3.org/bp

Translating Between RDO/RHOS and upstream releases Redux by Adam Young

I posted this once before, but we’ve moved on a bit since then. So, an update.

Read more at http://tm3.org/bq

View article »

How to run Rally on Packstack environment

Rally is a benchmarking tool that automates and unifies multi-node OpenStack deployment, cloud verification, benchmarking & profiling. For OpenStack deployment I used packstack tool.

Install Rally

[1.] Install rally:

$ sudo yum install openstack-rally

[2.] After the installation is complete set up the Rally database:

$ sudo rally-manage db recreate

Register an OpenStack deployment

You have to provide Rally with an OpenStack deployment it is going to benchmark. To do that, we're going to use keystone configuration file generated by packstack installation.

[1.] Evaluate the configuration file:

$ source keystone_admin

[2.] Create rally deployment and let's name it "existing"

$ rally deployment create --fromenv --name=existing
| uuid                                 | created_at                 | name     | status           | active |
| 6973e349-739e-41af-947a-34230b7383f8 | 2016-10-05 08:24:27.939523 | existing | deploy->finished |        |

[3.] You can verify that your current deployment is healthy and ready to be benchmarked by the deployment check command:

$ rally deployment check
| services    | type         | status    |
| ceilometer  | metering     | Available |
| cinder      | volume       | Available |
| glance      | image        | Available |
| gnocchi     | metric       | Available |
| keystone    | identity     | Available |
| neutron     | network      | Available |
| nova        | compute      | Available |
| swift       | object-store | Available |

Run Rally

The sequence of benchmarks to be launched by Rally should be specified in a benchmark task configuration file (either in JSON or in YAML format). Let's create one of the sample benchmark task, for example task for boot and delete server.

[1.] Create a new file and name it boot-and-delete.json

[2.] Copy this to the boot-and-delete.json file:

{% set flavor_name = flavor_name or "m1.tiny" %}
{% set image_name = image_name or "cirros" %}
    "NovaServers.boot_and_delete_server": [
            "args": {
                "flavor": {
                    "name": "{{flavor_name}}"
                "image": {
                    "name": "{{image_name}}"
                "force_delete": false
            "runner": {
                "type": "constant",
                "times": 10,
                "concurrency": 2
            "context": {
                "users": {
                    "tenants": 3,
                    "users_per_tenant": 2
            "args": {
                "flavor": {
                    "name": "{{flavor_name}}"
                "image": {
                    "name": "{{image_name}}"
                "auto_assign_nic": true
            "runner": {
                "type": "constant",
                "times": 10,
                "concurrency": 2
            "context": {
                "users": {
                    "tenants": 3,
                    "users_per_tenant": 2
                "network": {
                    "start_cidr": "",
                    "networks_per_tenant": 2

[3.] Run the task:

$ rally task start boot-and-delete.json

After successfull ran you'll see information such as: Task ID, Response Times, duration, … Note that the Rally input task above uses cirros as image name and 'm1.tiny' as flavor name. If this benchmark task fails, then the reason for that might be a non-existing image/flavor specified in the task. To check what images/flavors are available in the deployment you are currently benchmarking, you might use the rally show command:

$ rally show images
$ rally show flavors

More about Rally tasks templates can be found on Rally documentation

View article »

RDO Newton Released

The RDO community is pleased to announce the general availability of the RDO build for OpenStack Newton for RPM-based distributions, CentOS Linux 7 and Red Hat Enterprise Linux. RDO is suitable for building private, public, and hybrid clouds. Newton is the 14th release from the OpenStack project, which is the work of more than 2700 contributors from around the world (source).

The RDO community project curates, packages, builds, tests, and maintains a complete OpenStack component set for RHEL and CentOS Linux and is a member of the CentOS Cloud Infrastructure SIG. The Cloud Infrastructure SIG focuses on delivering a great user experience for CentOS Linux users looking to build and maintain their own on-premise, public or hybrid clouds. At latest count, RDO contains 1157 packages.

All work on RDO, and on the downstream release, Red Hat OpenStack Platform, is 100% open source, with all code changes going upstream first.

Getting Started

There are three ways to get started with RDO.

To spin up a proof of concept cloud, quickly, and on limited hardware, try the All-In-One Quickstart. You can run RDO on a single node to get a feel for how it works.

For a production deployment of RDO, use the TripleO Quickstart and you'll be running a production cloud in short order.

Finally, if you want to try out OpenStack, but don't have the time or hardware to run it yourself, visit TryStack, where you can use a free public OpenStack instance, running RDO packages, to experiment with the OpenStack management interface and API, launch instances, configure networks, and generally familiarize yourself with OpenStack

Getting Help

The RDO Project participates in a Q&A service at ask.openstack.org, for more developer-oriented content we recommend joining the rdo-list mailing list. Remember to post a brief introduction about yourself and your RDO story. You can also find extensive documentation on the RDO docs sites Documnentation, FAQS, Contribute, Storage, Books, Networking, Install.

The #rdo channel on Freenode IRC is also an excellent place to find help and give help.

We also welcome comments and requests on the CentOS mailing lists and the CentOS and TripleO IRC channels (#centos, #centos-devel, and #tripleo on irc.freenode.net), however we have a more focused audience in the RDO venues.

Getting Involved

To get involved in the OpenStack RPM packaging effort, see the RDO community pages and the CentOS Cloud SIG page. See also the RDO packaging documentation.

Join us in #rdo on the Freenode IRC network, and follow us at @RDOCommunity on Twitter. If you prefer Facebook, we're there too, and also Google+.

And, if you're going to be in Barcelona for the OpenStack Summit two weeks from now, join us on Tuesday evening at the Barcelona Princess, 5pm - 8pm, for an evening with the RDO and Ceph communities. If you can't make it in person, we'll be streaming it on YouTube.

View article »

Ceph/RDO meetup in Barcelona at OpenStack Summit

If you'll be in Barcelona later this month for OpenStack Summit, join us for an evening with RDO and Ceph.

Tuesday evening, October 25th, from 5 to 8pm (17:00 - 20:00) we'll be at the Barcelona Princess, right across the road from the Summit venue. We'll have drinks, light snacks, and presentations from both Ceph and RDO.

If you can't make it in person, we'll also be streaming the event on YouTube

Topics we expect to be covered include (not necessarily in this order):

  • RDO release status (aarch64, repos, workflow)
  • RDO repos overview (CBS vs Trunk, and what goes where)
  • RDO and Ceph (maybe TripleO and Ceph?)
  • Quick look at new rpmfactory workflow with rdopkg
  • CI in RDO - what are we testing?
  • CERN – How to replace several petabytes of Ceph hardware without downtime
  • Ceph at SUSE
  • Ceph on ARM
  • 3D Xpoint & 3D NAND with OpenStack and Ceph
  • Bioinformatics – Openstack and Ceph used in large scale cancer research projects

If you expect to be at the event, please consider signing up on Eventbrite so we have an idea of how many people to expect. Thanks!

View article »

RDO blog posts this week

Here's what RDO enthusiasts are blogging about lately.

Gnocchi 3.0 release by Julien Danjou

After a few weeks of hard work with the team, here is the new major version of Gnocchi, stamped 3.0.0. It was very challenging, as we wanted to implement a few big changes in it.

Read more at http://tm3.org/bf

# of DB connections in OpenStack services by geguileo

The other day someone asked me if the SQLAlchemy connections to the DB where per worker or shared among all workers, and what was the number of connections that should be expected from an OpenStack service. Maybe you have also wondered about this at some point, wonder no more, here’s a quick write up summarizing […]

Read more at http://tm3.org/bg

Hyperthreading in the cloud by Tim Bell

The cloud at CERN is used for a variety of different purposes from running personal VMs for development/test, bulk throughput computing to analyse the data from the Large Hadron Collider to long running services for the experiments and the organisation.

Read more at http://tm3.org/bh

OVS 2.6 and The First Release of OVN by russellbryant

In January of 2015, the Open vSwitch team announced that they planned to start a new project within OVS called OVN (Open Virtual Network).  The timing could not have been better for me as I was looking around for a new project.  I dove in with a goal of figuring out whether OVN could be a promising next generation of Open vSwitch integration for OpenStack and have been contributing to it ever since.

Read more at http://tm3.org/bi

Deployment tips for puppet-tripleo changes by Carlos Camacho

This post will describe different ways of debugging puppet-tripleo changes.

Read more at http://tm3.org/bj

Running Tempest on RDO OpenStack Newton by chandankumar

Tempest is a set of integration tests to run against an OpenStack cluster.

Read more at http://tm3.org/bk

View article »

Running Tempest on RDO OpenStack Newton

UPDATES: RDO Ocata introduces few changes that partially obsoletes the content of this article; check the updated article for details.

Tempest is a set of integration tests to run against an OpenStack cluster.

What does RDO provides for Tempest?

RDO provides three packages for running tempest against any OpenStack installation.

  • python-tempest : It can be used as a python library, consumed as a dependency for out of tree tempest plugins i.e. for horizon and designate tempest plugins.
  • openstack-tempest : It provides python tempest library and required executables for running tempest.
  • openstack-tempest-all : It will install openstack-tempest as well as all the tempest plugins on the system.

Deploy packstack using latest RDO Newton packages

Roll out a vm of CentOS 7, Follow these steps:

  1. Install rdo-release-newton rpm

     # yum -y install https://rdoproject.org/repos/openstack-newton/rdo-release-newton.rpm
  2. Update your CentOS vm and perform reboot.

     # yum -y update
  3. Install openstack-packstack

     # yum install -y openstack-packstack
  4. Run packstack to deploy OpenStack Newton release:

     # packstack --allinone

    Once packstack installation is done, we are good to go ahead.

Install tempest and required tempest plugins

  1. Install tempest

    # yum install openstack-tempest
  2. Install tempest plugins based on the openstack services installed and configured on deployment.

    Packstack installs by default horizon, nova, neutron, keystone, cinder, swift, glance, ceilometer, aodh and gnocchi. To find out what are the openstack components installed, just do a rpm query:

     # rpm -qa | grep openstack-*

    OR you can use openstack-status command for the same. Just grab the tempest plugins of these services and install it.

     # yum install python-glance-tests python-keystone-tests python-horizon-tests-tempest \
       python-neutron-tests python-cinder-tests python-nova-tests python-swift-tests \
       python-ceilometer-tests python-gnocchi-tests python-aodh-tests

    OR you can automatically install the required tempest plugins of the configured services on the environment.

     # python /usr/share/openstack-tempest-*/tools/install_test_packages.py
  3. To find what are tempest plugins installed:

     # tempest list-plugins

    Once done, you are ready to run tempest.

    If you face any entry point issues while running tempest, you can debug using entry_point_inspector tool Install entry_point_inspector from epel.repo.

         # yum install epel-release
         # yum install python-epi

    Run epi command to show the entry points of tempest plugins:

     # epi group show tempest.test_plugins

Configuring and Running tempest

  1. source admin credentials and switch to normal user

     # source /root/keystonerc_admin
     # su <user>
  2. Create a directory from where you want to run tempest

     $ mkdir /home/$USER/tempest; cd /home/$USER/tempest
  3. Configure the tempest directory

     $ /usr/share/openstack-tempest-*/tools/configure-tempest-directory
  4. Auto generate tempest configuration for your deployed openstack environment

    $ python tools/config_tempest.py --debug identity.uri $OS_AUTH_URL \
      identity.admin_password  $OS_PASSWORD --create

    It will automatically create all the required configuration in etc/tempest.conf

  5. To list all the tests

    $ testr list-tests


    $ ostestr -l
  6. To run tempest tests:

     $ ostestr
  7. For running api and scenario tests using ostestr and prints the slowest tests after test run

     $ ostestr --regex '(?!.*\[.*\bslow\b.*\])(^tempest\.(api|scenario))'
  8. To run specific tests:

     $ python -m testtools.run tempest.api.volume.v2.test_volumes_list.VolumesV2ListTestJSON


     $ ostestr --pdb tempest.api.volume.v2.test_volumes_list.VolumesV2ListTestJSON

    ostestr –pdb will call python -m testtools.run under the hood.

Thanks to Luigi, Steve, Daniel, Javier, Alfredo, Alan for the review.

Happy Hacking!

View article »

Recent RDO blogs, September 12, 2016

Here's what RDO enthusiasts have been blogging about in the last few weeks.

LinuxCon talk slides: “A Practical Look at QEMU’s Block Layer Primitives” by Kashyap Chamarthy

Last week I spent time at LinuxCon (and the co-located KVM Forum) Toronto. I presented a talk on QEMU’s block layer primitives. Specifically, the QMP primitives block-commit, drive-mirror, drive-backup, and QEMU’s built-in NBD (Network Block Device) server.

… read more at http://tm3.org/9x

Complex data transformations with nested Heat intrinsic functions by Steve Hardy

Disclaimer, what follows is either pretty neat, or pure-evil depending your your viewpoint ;) But it's based on a real use-case and it works, so I'm posting this to document the approach, why it's needed, and hopefully stimulate some discussion around optimizations leading to a improved/simplified implementation in the future.

… read more at http://tm3.org/9y

Red Hat OpenStack Platform 9 is here! So what’s new? by Marcos Garcia

This week we released the latest version of our OpenStack product, Red Hat OpenStack Platform 9. This release contains more than 500 downstream enhancements, bug fixes, documentation changes, and security updates. It’s based on the upstream OpenStack Mitaka release. We have worked hard to reduce the time to release new versions and have successfully done so with this release! Red Hat OpenStack Platform 9 contains new Mitaka features and functionality, as well as the additional hardening, stability, and certifications Red Hat is known for. Of course, there continues to be tight integration with other key portfolio products, as well as comprehensive documentation.

… read more at http://tm3.org/9z

Deploying Server on Ironic Node Baseline by Adam Young

My team is working on the ability to automatically enroll servers launched from Nova in FreeIPA. Debugging the process has proven challenging; when things fail, the node does not come up, and there is little error reporting. This article posts a baseline of what things look like prior to any changes, so we can better see what we are breaking.

… read more at http://tm3.org/9-

A retrospective of the OpenStack Telemetry project Newton cycle by Julien Danjou

A few weeks ago, I recorded an interview with Krishnan Raghuram about what was discussed for this development cycle for OpenStack Telemetry at the Austin summit.

… read more at http://tm3.org/a0

Deploying Fernet on the Overcloud by Adam Young

Here is a proof of concept of deploying an OpenStack Tripleo Overcloud using the Fernet token Provider.

… read more at http://tm3.org/a1

OpenStack Infra: Understanding Zuul by Arie Bregman

Recently I had the time to explore Zuul. I decided to gather everything I learned here in this post. Perhaps you’ll find it useful for your understanding of Zuul.

… read more at http://tm3.org/a2

OpenStack Infra: How to deploy Zuul by Arie Bregman

This is the second post on Zuul, which focuses on deploying it and its services. To learn what is Zuul and how it works, I recommend to read the previous post.

… read more at http://tm3.org/a3

Scaling-up TripleO CI coverage with scenarios by Emilien Macchi

When the project OpenStack started, it was “just” a set of services with the goal to spawn a VM. I remember you run everything on your laptop and test things really quickly. The project has now grown, and thousands of features have been implemented, more backends / drivers are supported and new projects joined the party. It makes testing very challenging because everything can’t be tested in CI environment.

… read more at http://tm3.org/a4

Introducing patches to RDO CloudSIG packages by Jakub Ruzicka

RDO infrastructure and tooling has been changing/improving with each OpenStack release and we now have our own packaging workflow powered by RPM factory at review.rdoproject.org, designed to keep up with supersonic speed of upstream development.

… read more at http://tm3.org/a5

From decimal to timestamp with MySQL by Julien Danjou

When working with timestamps, one question that often arises is the precision of those timestamps. Most software is good enough with a precision up to the second, and that's easy. But in some cases, like working on metering, a finer precision is required.

… read more at http://tm3.org/a6

Generating Token Request JSON from Environment Variables by Adam Young

When working with New APIS we need to test them with curl prior to writing the python client. I’ve often had to hand create the JSON used for the token request, as I wrote about way back here. Here is a simple bash script to convert the V3 environment variables into the JSON for a token request.

… read more at http://tm3.org/a7

Actionable CI by Assaf Muller

I’ve observed a persistent theme across valuable and successful CI systems, and that is actionable results. A CI system for a project as complicated as OpenStack requires a staggering amount of energy to maintain and improve. Often times the responsible parties are focused on keeping it green and are buried under a mountain of continuous failures, legit or otherwise. So much so that they don’t have time to focus on the following questions:

… read more at http://tm3.org/a8

Thoughts on Red Hat OpenStack Platform and certification of Tesora Database as a Service Platform by Ken Rugg, Chief Executive Officer, Tesora

When I think about open source software, Red Hat is first name that comes to mind. At Tesora, we’ve been working to make our Database as a Service Platform available to Red Hat OpenStack Platform users, and now it is a Red Hat certified solution. Officially collaborating with Red Hat in the context of OpenStack, one of the fastest growing open source projects ever, is a tremendous opportunity.

… read more at http://tm3.org/a9

View article »

Introducing patches to RDO CloudSIG packages

RDO infrastructure and tooling has been changing/improving with each OpenStack release and we now have our own packaging workflow powered by RPM factory at review.rdoproject.org, designed to keep up with supersonic speed of upstream development.

Let's see what it takes to land a patch in RDO CloudSIG repos with the new workflow!

The Quest

This is a short story about backporting an upstream OpenStack Swift patch into RDO Mitaka openstack-swift package.

Please consult RDO Packaging docs for additional information.

First Things First

Make sure you have latest rdopkg:

$ dnf install rdopkg

This is a new code added alongside existing functionality and it isn't well tested yet, bugs need to be ironed out. If you encounter rdopkg bug, please report how it broke.

Inspect rdoinfo package metadata including various URLs using rdopkg info:

$ rdopkg info openstack-swift

name: openstack-swift
project: swift
conf: rpmfactory-core
upstream: git://git.openstack.org/openstack/swift
patches: http://review.rdoproject.org/r/p/openstack/swift.git
distgit: http://review.rdoproject.org/r/p/openstack/swift-distgit.git
master-distgit: http://review.rdoproject.org/r/p/openstack/swift-distgit.git
review-origin: ssh://review.rdoproject.org:29418/openstack/swift-distgit.git
review-patches: ssh://review.rdoproject.org:29418/openstack/swift.git
  liberty: null
  mitaka: null
  newton: null
  newton-uc: null
- zaitcev@redhat.com

Yeah, that's the Swift we want. Let's use rdopkg clone to clone the distgit and also setup remotes according to rdoinfo entry above:

$ rdopkg clone [-u githubnick] openstack-swift

Which results in following remotes:

* origin:          http://review.rdoproject.org/r/p/openstack/swift-distgit.git
* patches:         http://review.rdoproject.org/r/p/openstack/swift.git
* review-origin:   ssh://githubnick@review.rdoproject.org:29418/openstack/swift-distgit.git
* review-patches:  ssh://githubnick@review.rdoproject.org:29418/openstack/swift.git
* upstream:        git://git.openstack.org/openstack/swift

Send patch for review

Patches are now stored as open gerrit review chains on top of upstream version tags so patches remote is now obsolete legacy.

Start with inspecting distgit:

$ git checkout mitaka-rdo
$ rdopkg pkgenv

Package:   openstack-swift
NVR:       2.7.0-1
Version:   2.7.0
Upstream:  2.9.0
Tag style: X.Y.Z

Patches style:          review
Dist-git branch:        mitaka-rdo
Local patches branch:   mitaka-patches
Remote patches branch:  patches/mitaka-patches 
Remote upstream branch: upstream/master
Patches chain:          unknown

OS dist:                RDO
RDO release/dist guess: mitaka/el7

rdopkg patchlog doesn't support review workflow yet, sorry.

Next, use rdopkg get-patches to create local patches branch from associated gerrit patches chain and switch to it:

$ rdopkg get-patches

Cherry-pick the patch into newly created mitaka-patches branch. Upstream source is available in upstream remote.

$ git cherry-pick -x deadbeef

Finally, send the patch for review with rdopkg review-patch which is just a convenience shortcut to git review -r review-origin $BRANCH:

$ rdopkg review-patch

This will print an URL to patch review such as https://review.rdoproject.org/r/#/c/1145/.

Get +2 +1V on the patch review

Patches are never merged, they are kept as open review chains in order to preserve full patch history.

You need to get +2 from a reviewer and +1 Verified from the CI.

Update .spec and send it for review

Once the patch has been reviewed, update the .spec file in mitaka-rdo:

$ git checkout mitaka-rdo
$ rdopkg patch

You can also select specific patches chain by review number with -g/--gerrit-patches-chain:

$ rdopkg patch -g 1337

Inspect the newly created commit which should contain all necessary changes. If you need to adjust something, do so and use rdopkg amend to git commit -a --amend with nice commit message generated from changelog.

Finally, submit distgit change for review with

$ rdopkg review-spec

Review URL is printed. This is a regular review and once it's merged, you're done.

Happy packaging!

View article »