Comment 19 for bug 1175211

Coming back to Jack's comment #16 ("can we restore some forward momentum to this?") I indeed wonder if there is a small, short term solution possible which suits at least most people. I am actually not sure that just waiting for the availablity of Moniker in the next release is the proper answers, especially as I failed to understand so far it it's not going to leave us with the same issue, just on a different technical platform.

Basically, I understand that discussion is all about how to find a name that can be assigned to a node. One solution discussed here but not actually accepted for reasons of backward compatibility IIUC was to use a port name. IMHO this would indeed onyl be the 2nd best option anyway as it would only buy us something if one sets up the port name properly *before* launching an instance.

Basically, the subject of DNS names and IP addresses comes down two two possible scenarios:

1. Either I do advanced planning, i.e. I know I will be launching 5 instances which are supposed to work together (for example 2 load balancers, two web servers and one admin instance). So I could make up names for them in advance (lb-1, lb-2, web-1, web-2, admin) and assign an IP address to each of them in the DHCP server, so once the instance will launch it will get assiged the proper name and IP address and all will be fine. Except, how would I know the MAC address that the new instances will be using in order to configure them in the DHCP server prior to having launched the instances. Sounds a bit like a chickend and egg problem to me. (I understand MAC addresses are generated with some randomness during the instance launch, right?)

2. In the other scenario I just hit the "Launch me an instance" button in Horizon five times in a row and type in my names, i.e. again lb-1, lb-2, you get it. So each instance will receive an arbitraty IP address from the DHCP pool and there is no way for the five instances to find each other on the network unless I would manually setup /etc/hosts entries for all of them in each of them, is there? Would they be able to refer to each other by given name I would have a prepared confuguration for example for the load balancers in which I write that the two backends are web-1 and web-2, without ever having to care about the IP addresses used. I guess this is what DNS was made for, right? So I guess I don't expect too much if I expect this to work.

A trivial solution IMO would be:

Add the --addn-hosts and the --dhcp-script options to the dnsmasq launched by Neutron.

The DHCP request of each instance which launches contains the node name which is derived from the instance name by making it DNS-compatible, i.e. replace spaces by dashed etc. This is happening today, at least with images which use Cloud Init (tested on Ubuntu). The dhcp script could just write the assiged IP address together with the name into the additonal hosts file and you're done.

To be honest, there would be some shortcomings, such as:

If an instance gets "terminated" (which is OpenStack's way of saying it's gone forever) the entry will stay there unless manually removed. I am not sure if there would be any hook which would allow to make sure that the corresponding line would get deleted again.

Also one would have to deal with duplicate instance names which are possible today, despite I wonder who would argue that it makes sense to have two identically named instances within the same network of the same tennant.

So the question is:

Did I overlook or misunderstand anything?
If not, I would be willing to provide a patch for dhcp.py if people think it would have a chance to get committed.
The question is primarily: Are there any unwanted side-effects introduced by what I suggest?

We could possibly still commit it as an alternative subclass of the Dnsmasq provider, can't we?