I'm wondering if we can restore some forward momentum to this. This is a nova parity issue, and a pain point for users.
Looking at Armando's comment on https://review.openstack.org/#/c/37098/5//COMMIT_MSG, he says "there should be a way to preserve the current behavior without using the port name as deciding factor". I think that's valid, and we could address it with a config option e.g. use_port_name_for_host_name=True/False.
Another option I had considered is adding a hostname attribute to the port object. I was trying to avoid this path as it brings in all the overhead of a new API extension.
A third option might be the extra_dhcp_opts extension. We could explicitly specify the hostname using this API, e.g. {"opt_value": "myvmname", "opt_name": "hostname"}. I think we'd need to tweak _output_hosts_file a bit to use this, but at least it is an existing API mechanism that could be used.
I'm wondering if we can restore some forward momentum to this. This is a nova parity issue, and a pain point for users.
Looking at Armando's comment on https:/ /review. openstack. org/#/c/ 37098/5/ /COMMIT_ MSG, he says "there should be a way to preserve the current behavior without using the port name as deciding factor". I think that's valid, and we could address it with a config option e.g. use_port_ name_for_ host_name= True/False.
Another option I had considered is adding a hostname attribute to the port object. I was trying to avoid this path as it brings in all the overhead of a new API extension.
A third option might be the extra_dhcp_opts extension. We could explicitly specify the hostname using this API, e.g. {"opt_value": "myvmname", "opt_name": "hostname"}. I think we'd need to tweak _output_hosts_file a bit to use this, but at least it is an existing API mechanism that could be used.
Thoughts?