Open Stack

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20170925/2aa066f8/attachment.html>