Hi Matt,

On 9/22/17 7:10 PM, Matt Riedemann wrote:

while this approach is ok in general, some comments from my side -
1. For a new instance, if the neutron network has a dns_domain set, use it. I'm not totally sure how we tell from the metadata API if it's a new instance or not, except when we're building the config drive, but that could be sorted out.
In some scenarios, ports can be created for VM but be detached until "right" time. For example, at the moment Nova don't reflect Neutron's port admin state to VM (long time was going to, but thanks to this discussion just filled a bug https://bugs.launchpad.net/nova/+bug/1719261 ). So, if you need VM with predefined port roles (with corresponding iptables rules), but, for some reasons, these ports should be DOWN, you need:

- create them before VM will be created
- pass their MAC addresses to VM in order to create corresponding udev naming rules and subsequent configuration
- but don't attach them

In such scenario, network with "dns_domain" parameter can be unavailable to VM since there are no attached ports from this network at the VM creation time.

And a second point: what I wanted to say is that "dns_domain" is a property, which is available only when Designate is in use. While it can be immanent property of network for use with dnsmasq's "--domain" parameter, in order to get useful responces for DHCP "domain" queries. Not too critical, but full integration with DNS don't always required while simple DHCP functionality is enough.

2. Otherwise use the dhcp_domain config option in nova.
Crazy idea is to get customization right here - if instance's "name" is FQDN itself (e.g. myhost.some.domain.here) then:
- ignore "dhcp_domain" and pass "name" unchanged as hostname to VM
- but use "hostname"-part of name (e.g. myhost) to register VM in Openstack

Thank you.

--
Volodymyr Litovka
  "Vision without Execution is Hallucination." -- Thomas Edison

_______________________________________________
OpenStack-operators mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Reply via email to