yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #64230
[Bug 1693265] [NEW] network_data.json should provide interface-scoped nameserver information
Public bug reported:
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.
** Affects: nova
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1693265
Title:
network_data.json should provide interface-scoped nameserver
information
Status in OpenStack Compute (nova):
New
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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1693265/+subscriptions
Follow ups