Dry-Run Testing in the RIPE Database

Denis Walker — Sep 09, 2013 11:00 AM
Filed under:
Have you ever wanted to test an update to the RIPE Database, without actually changing anything in the database? Well now you can "dry-run" it - see what will happen without changing anything.

Introduction

We have always suggested that if you want to "try" an update to see what happens, you should do so in the TEST Database. But the TEST Database is a sterile land with hardly any data in it. We also reset it every day. So if you want to test anything that has dependencies on other data you have to reproduce it all in the TEST Database to do the test. That in itself can be a major effort. And tomorrow it is all gone.

To address this, we have introduced a simple new feature - "dry-run" - that lets you test updates on the production RIPE Database. All your data is there. All dependencies are taken care of. Submit your update and see what the result will be. But nothing actually changes. It is perfectly safe.

How do I use it?

Submit an update by any update method: Syncupdates, Webupdates, REST API or email. At the moment we can only process a single object in the update. To handle multiple objects in using "dry-run" could be done, but it would require much more work to set it up. If the interest is there we can add this later.

Enter whatever you want for this single object. Use the correct syntax or include deliberate errors, full set of credentials or not - it all depends what you want to test. Somewhere in the update enter the "dry-run:" pseudo attribute on a new line:

dry-run:

It does not need a value, but if you add any text it will be ignored. It can be anywhere in the update message, just as "password:" can be. Then submit the update.

What happens?

The update is received by the RIPE Database production software. We do all the checks on it:

  • Syntax
  • Business rules
  • Authorisation
  • Referential integrity

Then we stop! Nothing is changed in the RIPE Database.

What do I see?

An acknowledgement message is returned to the user who submited the update by the normal channels, depending on the input method used. No notifications are sent. So only the user who is testing the update gets the results. For a dry-run update that would modify an object, the diff output that would normally be in the notification message is added to the dry-run acknowledgement message. This helps to show what would be changed by an actual update.

Summary

What if...? What would happen...? How would it look...? Would this work...? These type of questions can now be answered by a simple dry-run update. Why not give it a try and see if it is useful for you.

Please let us have some feedback below, good or bad - we would like to know what you think!

0 Comments

Add comment

You can add a comment by filling out the form below. Only plain text is possible. Web and email addresses will be transformed into clickable links. Comments are moderated so they won't appear immediately.

Related Items
A New RIPE Database Prototype

The RIPE NCC is improving the RIPE Database functionality and usability by introducing a trial of ...

New and Improved RIPE Registry Global Resource Service

We have redesigned and improved the way we mirror other databases. We now have a method of ...

Abuse Handling in the RIPE Database

This article describes a technical design for the introduction of abuse contact details in the RIPE ...

Updated Heuristics for the Abuse Finder Service

This article outlines some of the refinements made to the Abuse Finder tool based on community ...

Updates to the RIPE Database Query API and Search Clients

Since the first announcement of the RIPE Database Query API, some changes and additions have been ...

more ...