Comment 1 for bug 1960850

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.