Lucas 37.0 released!

With an incredibly reliable cadence, here we have Lucas 37.0 out! This release is mostly about a few bugfixes and improvements, that come with experience, and a new hosting city.

That’s right, after 5 great years in Piracicaba, the entire family project is in the process of moving to Berlin, Germany. The prospect of moving to a different hosting city and country was something contemplated for years, and it has finally happened. We’re looking forward the new adventures in our new home.

On related news, Victoria 14.0 was out of the door last December, and the parent project could not be prouder of the amazing human being she’s turning out to be.

My fiancee Silvia completed her 26th milestone last December as well, and we’re to become companion projects for life in May 2017. I for one wish us luck, love and happiness for the years to come.

And for the readers, I wish peace and prosperity. To another great year, off we go!


Farewell Red Hat

A couple weeks ago, I worked my last day at Red Hat, after 6 and a half years of service. Once again, I had a great time working with awesome team mates. In the mean time we made a lot of autotest releases and even started the follow up to autotest, avocado. It was a difficult decision to leave an organization that is so near and dear to my heart.

But time has come, and I have a new challenge. I’m starting a new job at ScyllaDB, a company founded by a bunch of other former Red Hatters that is delivering nothing less than the fastest new generation database there is. Wish me luck!

5 years of Red Hat!

en-US: Yesterday, I completed 5 years working for Red Hat. I’m proud to be a part of this company, helping to make Free/Open Source software better and sharing a great deal of what I produce with everybody. I’m looking forward to the next years 🙂

pt-BR: Ontem, completei 5 anos trabalhando para a Red Hat. Estou orgulhoso por ser parte desta empresa, ajudando a tornar o Software Livre/Open Source melhor, e compartilhando grande parte do que produzo com todos. Aguardo ansioso pelos próximos anos 🙂 

Lucas 34.0 released!

Hello boys and girls, on 04/04 Lucas 34.0 was just released! Without further ado, here are the new features of the project:

The offspring project called Victoria had its 11th release last December and is starting to show the first bugs of a project in its teenage cycle 

The dating subsystem is about to complete its 3rd year, being one of the highest quality subsystems to date!

Many of the long standing bugs related to work-life balance were fixed, and add up to the extended maintenance initiative.

Once again, thanks to all the wonderful people in project management, development and QA! If it weren’t for you, this project wouldn’t ever leave its first prototypes. Cheers!

Remove rpm packages with failed scriptlets execution

Have you ever been in that awkward spot where an rpm package had a scriptlet error, and you can’t remove it from your system, ever? I have to do this from time to time, but end up forgetting how it’s done. Let’s change that by keeping it in this blog (incidentally helping other people):

rpm -e --noscripts --justdb [packagename-version]

That was easy 🙂

Lucas version 33.0 released!

This is an auspicious post, given it is my 100th post on this blog. I thought I wouldn’t make this far, but anyway…

Is that time of the year again! Lucas 33.0 was just released. This mature yet ever evolving project reaches its 33rd milestone. Among the new features and news we have:

  • The offspring project called Victoria had its 10th release last December and is expected to reach teenage status soon 🙂 She is growing to be a lovely, caring and compassionate offspring project, which makes her parent project very happy!
  • The parenting, and housekeeping subsystems once again were improved, in the beautiful Piracicaba, which is proving to be an excelent hosting city for this project. The dating subsystem is about to have a release 2.0 (and I wish many more releases to come).
  • 33.0 continues to be very solid and reliable, due to the extended maintenance initiative. Let’s keep the extended maintenance, by hitting the gym, healthy eating and plenty of sleep!

There has been some especulation that the project team is moving to a rolling release, but these are only speculations. The yearly releases are expected to come for the forseeable future, since it is a meaningful measure of human progress 😉 It might be that in the future we’ll all get bored with the release notes, but so far, it’s been a lot of fun!

Autotest 0.15.0 released!

Autotest 0.15.0 is a new major release of autotest! The goal here is to provide the latest advances on autotest while providing a stable ground for groups and organizations looking for autotest, such as distro packagers and newcomers.

For the impatient

Check out our main web page at:

Direct download link:

Now that github removed arbitrary uploads, we now will release directly fom git tags. The tags now will be signed with my GPG key. So get your fresh copy of autotest (remember, the tarball does not contain the tests anymore, those must be picked at the new test repos).


Tests modules split

Since test modules are fairly independent from the core framework, they have been split into their own new git repos, and were added to autotest as git submodules. Don’t worry, if you want the autotest repo with full tests, you may only need to execute

git clone –recursive git://

The new repositories for the client and server tests:

API cleanup

Following the example of autotest 0.14.0, 0.15.0 brings more API cleanups.

1) global_config -> settings

The library global_config was renamed to settings. As an example of how
the change works, here’s an example of how to access settings on autotest

from autotest.client.shared import global_config

c = global_config.global_config.get_config_value
c.get_value("mysection", "mykey")

This is how the same process look on autotest 0.15.0:

from autotest.client.shared.settings import settings

settings.get_value("mysection", "mykey")

As tests usually have no business with the autotest settings, this means
pretty much no update required from test authors.

Machine installs from the autotest web interface

In autotest 0.14, we introduced preliminary integration between autotest

and the Cobbler install server ( was introduced. However, there was not enough of that integration visible if you were using the web interface. Now it is possible to select which cobbler profiles you want to use on your test machines from the web interface.

DB migration moved to Django South

When the autotest RPC server application was developed, there was a database code in place already. In order to move away from having 2 ways to access the database, this version of autotest introduces a new migration system, based on Django South (

For people looking for upgrading the database to the latest version, we’ve put up a procedure here

Other changes

* Support for creation of debian packages

* Simplified module import logic
* Simplified unittests execution
* Improved install scripts. Now it is possible to install autotest from an arbitrary git repo and branch, which will make it easier to test and validate changes that involve the rpc client/server, scheduler, among others.

What’s next?

We believe the foundation for an autotest version 1.0 is already in place. So, the next release will be autotest 1.0, bringing polish and bugfixing to the framework being developed during the previous six years.

You can see the issues open for the Milestone 1.0.0 here:

and here:

For autotest 1.0 we plan on upgrading the stack to the latest versions
of the foundation technologies involved in the server operation, and
package generation:

* Update the web interface (RPC client) to the latest GWT

* Update the RPC server to the latest Django

* Functional server packages for Debian
* Automated generation of both rpm and debian packages
* Functional regression test suite for server installs, working out of the box

We also want to improve the usefulness and usability of our existing tools

* Introduce a ‘machine reserve’ mode, where you may provision one bare metal machine with the OS of choice and use the installed machine for a period of time, in a convenient way.

* Allow to schedule jobs based on machine hardware capabilities, for example:
– Number of CPUS
– Available Memory
– Virtualization support
among others

* Allow autotest to function well as an alternative test harness for beaker (

* Support to parametrized jobs (be able to set parameters in tests, and enable people to simply pass parameters to those tests in the cli/web interface).