DNS management system for OpenStack

`nova-dns` package was developed to solve two tasks:

  • map instance’s hostnames to ip addresses in DNS
  • provide REST API to manage DNS

To solve first task service monitor message bus (RabbitMQ). For every started instance service add DNS record, for terminated – remove.  DNS name is choose in form hostname.tenant_name.root_zone. If zone for tenant_name doesn’t exists yet, it is created and populated automatically.

To solve second task service start REST API server on specified ip/port. REST API supports authentication against keystone and utilize keystone’s RBAC.

As a DNS backend PowerDNS is used, but other backends (for example for Bind) can be added later.

Next we are going to add support for PTR zones and  add ability to create personal zone for every started instance.

Links:

About these ads

6 thoughts on “DNS management system for OpenStack

  1. Ryan Lane

    We have competing implementations. Is there any way we can merge these, or work together somehow, rather than implement the same thing in different ways? Our implementation is already included with nova in essex.

    Reply
    1. Dmitry Maslennikov

      We have competing implementations. Is there any way we can merge these, or work together somehow, rather than implement the same thing in different ways? Our implementation is already included with nova in essex.

      Your implementation (if it is what I can see in official nova repository) is very different from our. In my opinion nova should not be a all in one service. Separate service is more flexible, potentially can be more scalable and can be more secure. Our DNS can be used without nova at all. We just use same authentication service (keystone) and able to listen RabbitMQ bus to automatically add or remove records related to VMs.

      Reply
  2. Pingback: Community Weekly Review (Feb 10-17) - openstackAPI | openstackAPI

  3. Pingback: SquareCows.com » Community Weekly Review (Feb 10-17)

    1. David Andrew

      Andrey, not that it matters now but it fails and crashes, there are a couple of forks that have made the necessary changes to work with essex and overwrite previous entries essentially leaving the original instance in DNS no mans land. In the end, Folsom changed the way it launches it’s components to allow multiple threads and the project is once again in a broken state.

      Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s