It’s a bit of an embarrassment when you submit a review to Gerrit only to have it fail CI checks immediately because of something as simple as a syntax error or pep8 failure that you should have caught yourself before submitting…but you forgot to run your validations before submitting the change.

In many cases you can alleviate this through the use of the git pre-commit hook, which will run every time you commit changes locally. You can have the hook run tox or whatever tool your project uses for validation on every commit. This works okay for simple cases, but if the validation takes more than a couple of seconds the delay can be disruptive to the flow of your work.

The Newton release of Heat adds support for a yaql intrinsic function, which allows you to evaluate yaql expressions in your Heat templates. Unfortunately, the existing yaql documentation is somewhat limited, and does not offer examples of many of yaql’s more advanced features.

I am working on a Fluentd composable service for TripleO. I want to allow each service to specify a logging source configuration fragment, for example:

parameters:
  NovaAPILoggingSource:
    type: json
    description: Fluentd logging configuration for nova-api.
    default:
      tag: openstack.nova.api
      type: tail
      format: |
        /(?<time>\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}.\d+) (?<pid>\d+) (?<priority>\S+) (?<message>.*)/
      path: /var/log/nova/nova-api.log
      pos_file: /var/run/fluentd/openstack.nova.api.pos

This generally works, but several parts of this fragment are going to be the same across all OpenStack services. I wanted to reduce the above to just the unique attributes, which would look something like:

Let’s say that you have set up an environment using tripleo-quickstart and you would like to add another virtual machine to the mix that has both “external” connectivity (“external” in quotes because I am using it in the same way as the quickstart does w/r/t the undercloud) and connectivity to the overcloud nodes. How would you go about setting that up?

For a concrete example, let’s presume you have deployed an environment using the default tripleo-quickstart configuration, which looks like this:

This is a small collection of simple git tips and tricks I use to make my life easier.

Quickly amend an existing commit with new files

I have this alias in place that will amend the current commit while automatically re-using the existing commit message:

alias.fix=commit --amend -C HEAD

With this in place, fixing a review becomes:

$ vim some/file/somewhere
$ git add -u
$ git fix

Which I find much more convenient than git commit --amend, following by saving the commit message.

In this article I would like to introduce tripleo-quickstart, a tool that will automatically provision a virtual environment and then use TripleO to deploy an HA OpenStack on top of it.

Introducing Tripleo-Quickstart

The goal of the Tripleo-Quickstart project is to replace the instack-virt-setup tool for quickly setting up virtual TripleO environments, and to ultimately become the tool used by both developers and upstream CI for this purpose. The project is a set of Ansible playbooks that will take care of:

In my last article article I introduced Gruf, a command line tool for interacting with Gerrit. Since then, Gruf has gained a few important new features.

Caching

Gruf will now by default cache results for five minutes. This avoids repeatedly querying the server for the same information when you’re just displaying it with different templates (for example, if you run a gruf query open here followed by a gruf -t patches query open here).

(See also the followup to this article.)

I’ve recently started spending more time interacting with Gerrit, the code review tool used both by OpenStack, at review.openstack.org, and by a variety of other open source projects at GerritForge’s GitHub-linked review.gerrithub.io. I went looking for command line tools and was largely disappointed with what I found. Many of the solutions out there assume that you’re regularly interacting with a single Gerrit instance, and that’s seldom the case: more often, the Gerrit server in use varies from project to project.
I also found that many of the tools were opinionated in what sort of output they would produce.

I wrote earlier about systemd-nspawn, and how it can take much of the fiddly work out of setting up functional chroot environments. I’m a regular Ansible user, and I wanted to be able to apply some of those techniques to my playbooks.

Ansible already has a chroot module, of course, but for some situations – such as targeting an emulated chroot environment – that just means a lot of extra work. Using systemd-nspawn makes this trivial.

If you have an Ansible inventory file that includes lots of per host variables, it’s not unusual for lines to get long enough that they become unwieldly, particularly if you want to discuss them in an email or write about them in some context (e.g., a blog post).

I’ve just submitted pull request #14359 to Ansible which implements support for folding long lines using the INI-format convention of using indent to mark extended logical lines.

systemd-nspawn has been called “chroot on steroids”, but if you think of it as Docker with a slightly different target you wouldn’t be far wrong, either. It can be used to spawn containers on your host, and has a variety of options for configuring the containerized environment through the use of private networking, bind mounts, capability controls, and a variety of other facilities that give you flexible container management.

There are many different ways in which it can be used. I’m going to focus on one that’s a bit of a corner use case that I find particularly interesting. In this article we’re going to explore how we can use systemd-nspawn to spawn lightweight containers for architectures other than that of our host system.