[RFE][OVN] Support DNS subdomains at a network level
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
neutron |
New
|
Wishlist
|
Unassigned |
Bug Description
Right now we can only set domain names at a global level, using the dns_domain parameter neutron.conf file.
However, there are use cases where it is useful to provide more granularity to DNS, like at a network or port level where the dns_domain attribute exists.
This is feasible with the OVN driver because OVN sets the DNS naming at a port level:
[root@controller-0 /]# ovn-nbctl list DNS
_uuid : 9f8ce4cf-
external_ids : {ls_name=
records : {server1=
Thus, we could create an option to allow DNS using network naming as subdomains.
e.g.:
Global dns_domain: example.org
Networks: net-a, net-b
Server in Network A: server1
Server in Network B: server1
FQDN for server1 in network A: server1.
FQDN for server1 in network B: server1.
This would allow servers from different networks with the same name to have unique FQDNs, as opposed to the current approach were we would get the same FQDN in both cases: server1.example.org
description: | updated |
tags: | added: rfe |
Changed in neutron: | |
importance: | Undecided → Wishlist |
In a multitenant environment, where the OpenStack admin(s) has(have) limited control over what users can do, there are at least two use cases that could greatly benefit from this RFE:
1) different users working on different projects use common hostnames for their VMs (server1, web001,…) which leads to a FQDN conflict. As users don’t even know the hostnames other VMs have, they may inadvertently cause trouble with an unexpected FQDN clash;
2) users working on different stages of the same application may want to re-use hostnames and simply distinguish stages based on the subdomain. Example: app001. uat.example. com (for UAT) vs app001. prd.example. com (for Production) both have the same hostname.
This kind of advantage is even greater in environments where (non-shared, provider) networks are already mapped to OSP projects, for example for IPAM purposes. Such a 1:1 subnet:project mapping could translate, under this RFE, in a further 1:1 subnet:subdomain cardinality, which would allow anyone to immediately identify, given an FQDN, what project that VM belongs to, improving visibility, troubleshooting (think log parsing),…
Alternative approaches relying on cloud-init obviously don’t work on VMs not supporting cloud-init (virtual appliances, Windows,…). Once again, in a multitenant IaaS the OpenStack provider doesn’t necessarily control the images that are being deployed.
A native solution at the Neutron/OVN layer would be the best fit in these scenarios.