network_data.json should provide interface-scoped nameserver information

Bug #1693265 reported by Lars Kellogg-Stedman on 2017-05-24
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Medium
Lars Kellogg-Stedman
cloud-init
Medium
Unassigned

Bug Description

Nova currently provides nameserver information in network_data.json as a globally-scoped "services" key. E.g., from https://specs.openstack.org/openstack/nova-specs/specs/liberty/implemented/metadata-service-network-info.html#rest-api-impact:

  {
  "links": [...],
  "networks": [...],
  "services": [
      {
          "type": "dns",
          "address": "8.8.8.8"
      },
      {
          "type": "dns",
          "address": "8.8.4.4"
      }
    ]
  }

This is problematic because nameserver information is actually provided to OpenStack *per-subnet*, and nameservers that are reachable via one subnet may not be reachable from others. This is true outside of OpenStack as well, and is generally handled by providing nameserver information in interface configuration files (such as /etc/sysconfig/network-scripts/ifcfg-eth0 on RHEL and derivatives).

Unfortunately, because Nova does not provide interface-scoped nameserver information, it is not possible to correctly configure a server from this information. Depending on how /etc/resolv.conf is populated, this can result in name resolution delays or failures if some system interfaces are brought down.

While it may be too late to remove the global nameserver information, we should *also* provide interface-scoped nameserver information in the "networks" dictionary, something like:

  "networks": [
    {
      "network_id": "100dc63c-e8f8-46d1-a99f-6da4aca171b1",
      "type": "ipv4",
      "netmask": "255.255.255.0",
      "link": "tap14c7fd7d-81",
      "routes": [
        {
          "netmask": "0.0.0.0",
          "network": "0.0.0.0",
          "gateway": "10.9.8.1"
        }
      ],
      "ip_address": "10.9.8.2",
      "id": "network1",
      "services": [
        {
          "type": "dns",
          "address": "10.9.8.1"
        }
      ]
    }
  ]

This would allow system configuration tools to correctly configure interface-scoped nameserver information.

Fix proposed to branch: master
Review: https://review.openstack.org/467699

Changed in nova:
assignee: nobody → Lars Kellogg-Stedman (larsks)
status: New → In Progress
Matt Riedemann (mriedem) on 2017-07-20
Changed in nova:
importance: Undecided → Wishlist
Dan Smith (danms) wrote :

I changed the severity here because I don't think this is wishlist. Without a change, cloud-init has no option but to configure each interface with all the DNS servers. If you then take down an interface via which one of the per-net servers is reachable, you break resolution. Right now, multi-interface instances are being configured wrong, and thus that's a real issue.

Changed in nova:
importance: Wishlist → Medium

Reviewed: https://review.openstack.org/467699
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=4b333b989dfc778a8b61db4a1b8552e988a10471
Submitter: Jenkins
Branch: master

commit 4b333b989dfc778a8b61db4a1b8552e988a10471
Author: Lars Kellogg-Stedman <email address hidden>
Date: Wed May 24 12:40:13 2017 -0400

    provide interface-scoped nameserver information

    DNS nameserver information is subnet-specific, but nova provides this
    information globally, which makes it impossible for system
    configuration tools to place the nameserver information in the right
    place (e.g., in interface configuration files). This commit modifies
    nova to *also* provide the DNS information per-subnet, where it can be
    accessed by tools that want to configure the system properly.

    Change-Id: I003a25b0d60cb6cd16c3ee1ad1a43910825622be
    Closes-bug: #1693265

Changed in nova:
status: In Progress → Fix Released
Scott Moser (smoser) on 2017-08-01
Changed in cloud-init:
importance: Undecided → Medium
status: New → Confirmed

This issue was fixed in the openstack/nova 16.0.0.0rc1 release candidate.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers