To quote Homer Simpson: “All my life I’ve had one dream, to achieve my many goals.”.
One of my more recent goals is a desire to have real continuous integration testing for database migrations in Nova. You see, at the moment, database migrations can easily make upgrades painful for deployers, normally by taking a very long time to run. This is partially because we test on trivial datasets on our laptops, but it is also because it is hard to predict the scale of the various dimensions in the database — for example: perhaps one deployment has lots of instances; whilst another might have a smaller number of instances but a very large number of IP addresses.
The team I work with at Rackspace Australia has therefore been cooking up a scheme to try and fix this. For example, Josh Hesketh has been working on what we call Turbo Hipster, which he has blogged about. We’ve started off with a prototype to prove we can get meaningful testing results, which is running now.
Since we finished the prototype we’ve been working on a real implementation, which is known as Turbo Hipster. I know it’s an odd name, but we couldn’t decide what to call it, so we just took a suggestion from the github project namer. Its just an added advantage that the OpenStack Infra team think that the name is poking fun at them. Turbo Hipster reads the gerrit event stream, and then uses our own zuul to run tests and report results to gerrit. We need our own zuul because we want to able to offer federated testing later, and it isn’t fair to expect the Infra team to manage that for us. There’s nothing special about the tests we’re running; our zuul is capable of running other tests if people are interested in adding more, although we’d have to talk about if it makes more sense for you to just run your own zuul.
Generally I keep an eye on the reports and let developers know when there are problems with their patchset. I don’t want to link to where the reports live just yet. Right now, there are some problems which stop me from putting our prototype in a public place, though. Consider a migration that takes some form of confidential data out of the database and just logs it. Sure, we’d pick this up in code review, but by then we might have published test logs with confidential information. This is especially true because we want to be able to run tests against real production databases, both ones donated to run on our test infrastructure and ones where a federated worker is running somewhere else.
We have therefore started work on a database anonymization tool, which we named Fuzzy Happiness (see earlier comment about us being bad at naming things). This tool takes markup in the sqlalchemy models file and uses that to decide what values to anonymize (and how). Fuzzy Happiness is what prompted me to write this blog post: Nova reviewers are about to see a patch with strange markup in it, and I wanted something to point at to explain what we’re trying to do.
Once we have anonymization working there is one last piece we need, which is database scaling. Perhaps the entire size of your database gives away things you don’t want leaked into gerrit. This tool is tentatively codenamed Elastic Duckface, and we’ll tell you more about it just as soon as we’ve written it.
I’d be very interested in comments on any of this work, so please do reach out if you have thoughts.