Icon Rufen Sie uns an
+49 441.309197-69 +49 441.309197-69

Roadmap infrastructure database 2017

Posted by Felix Kronlage on Thursday, April 27, 2017

As we expose more customers to the infrastructure database and present the IDB at conferences more ideas pop up what to do next and what kind of features we - as well as customers - want to see within the product. With the release of the IDB-core as well as the adapters on github under OSI-approved licenses last year, we've accomplished the major milestone for the first year: Make sure that an internal tool becomes an open source solution.

We're currently within the scope of the 1.6 version. The versioning and development scheme of the IDB is fairly simple: We develop on the development branch, this is the default branch for the project, from which new versions are cut on release branches. For the 1.6 line we've reached the point where we will only add bug-fixes that are critical to a customer. That's why there is now a 1.6 branch from which potential 1.6.4, 1.6.5 releases will be made.

While the features of the IDB-core are tied to the main IDB version, features that only concern adapters are not coupled to this. As such, we have a version-based roadmap for IDB-core and a roadmap for the adapters. The roadmap lists all the major features to give you an idea on where we are heading, but it does not cover all the little improvements, bug-fixes and smaller ideas we are working on. For these, please check the issue tracker over at github.

Roadmap of IDB-core

Version 1.7 - to be released at the end of the second quarter 2017.

The 1.7 version will provide two major features that we've been working on this year:

  • Multi-Tenancy
  • The V3 version of the API


The IDB has the concepts of owners. Owners are associated with ressources like machines, inventory items and such. The multi-tenancy allows to scope the view of users within the IDB to a set of owners. We have a blogpost in the pipeline on how we implemented this.


With the third version of the API we want to introduce visibility of all ressources and not just machines and software components. For this to work in a good fashion, we had to make sure that we have scoped visibility first - which is the ground work of the multi-tenancy. From the list of things that the APIv3 will enable us to do, you see that this is one of the major items in the near future:

The APIv3 will allow us to access the complete datamodell of the IDB and opens us to the possiblity to finally add our NeDI as well as oxidized integration, since not only switches and networks can be added via the API as well, we can also attach files to objects in order to store router and firewall configurations.

The Ansible adapter mentioned in the section on adapters further down in this post will rely on the APIv3 and will be part of our work towards version 1.7.

Furthermore we want to look into reporting functionality - however this should not live inside the core application but instead be done by a real reporting tool. With the APIv3 it should be possible to hook software like JasperReports into the IDB for reporting.

Version 1.8 - to be released at the end of the third quarter 2017.

Major items for version 1.8 will be:

  • Password and credential management via Vault
  • Dashboard view with widgets
  • Expectation management

Password and credential management via Vault

An integrated password manager based on Hashicorp's Vault will be one of the major 1.8 features. Since the IDB adapters crawl lots of information sources, and we would want to store arbitrary credentials to ressources in a secure manner, anyways adding a password management for the users is another nice benefit.


The current interface is very technical and and not very appealing. For many tasks the table based UI is helpful, for quick overviews a dashboard-like interface could be very appealing as well. The idea is that users can create their own reporting widgets on the dashboard, for example to always list the ten machines that have the oldest serviced date. Most of the time, I look at the same set of data to begin with anyways.

Expectation management

Expectation management is the feature where we want to highline differences between the expected state of a ressource and the actual state. We will start this feature by adding the possiblity to submit network scans to the API of the IDB, and display whether any network ports are open on a maschine that should not according to the configuration within the idb. The application should then warn about this. Since we expose this kind of information over the API as well, one could even hook this into a monitoring system, that checks the IDB regularly for objects that do not reflect the desired state and alert upon that. Important: the infrastructure database is about aggegrating and summarizing information, the alerting needs to be done from the corresponding alerting tool.

Version 2.0 - to be released in time for christmas 2017.

For the 2.0 version we will only have the compliance feature on the agenda. We want to reserve development time for fine-graining the features that we added throughout the 1.7 and 1.8 release cycles.


The underlaying architecture of the core application already tracks changes to the objects. How cool would it be, if we would extend that with WORM functionality, so that the history of an object in the IDB can not be tampered with. If a system represented a certain state at one moment, this should be visible in the IDB and it should not be possible to adjust the past to match expectations.

Roadmap for the adapters

This is a list of adapters we will focus on throughout 2017.


The idbiaas adapter crawls various Infrastructure-as-a-service providers. We've started with DigitalOcean as well as libvirt-based environments. The next ones we want to add:

  • OpenStack
  • Amazon AWS
  • CloudStack

Ansible adapter

Since Ansible became quite popular, and couple of our partners and customers showed interest in having support for Ansible, we will provide an ansible adapter. Part of this work will be to make sure the IDB can serve as an external node classifier / inventory provider for Ansible as well.

OPSI adapter

OPSI is a solution for client management and has (as a linux-server based solution) a strong focus on Windows desktops. This is something we do not cover very well at the moment. Our idbad adapter is an attempt to gather information in Windows-based environments. OPSI features a nice REST-API and not only holds information about the machines but since it is used to distribute software to the clients, we can gather all the infos on the rolled-out software from it as well.

PuppetDB adapter

We've originated with the IDB with a strong focus on Puppet as an information source. As such, the PuppetDB information retrieval is currently not handled via an adapter, but as an internal process within IDB-core. To assure that all data that enters the infrastructure database goes via the one central point, we're going to rework the PuppetDB connection to a proper adapter.