Nova metadata service returns wrong hostname after neutron-api dns-domain config is set
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Neutron API Charm |
Fix Released
|
Medium
|
David Ames | ||
OpenStack Neutron Gateway Charm |
Fix Released
|
High
|
David Ames | ||
OpenStack Nova Cloud Controller Charm |
Fix Released
|
Medium
|
David Ames | ||
OpenStack Nova Compute Charm |
Fix Released
|
High
|
David Ames |
Bug Description
We are facing an issue to configure metadata service correctly. Neutron API charm's dns-domain was configured for an specific value but nova metadata service continues to return original "NAME_OF_
dns-domain seems to correctly configure DHCP domain name.
curl http://
{"random_seed": "redacted", "type": "ssh", "name": "dnstest"}], "hostname": "tdnsserver.
While /var/lib/
However, not all types of Guest OS follow DHCP's definition of domain. RHEL-based guest OS, for example, set their hostnames to the value present on metadata service despite DHCP's original configuration. Although one can work-around this by using user_data flag on "openstack server create" and setting "preserve_hostname: true", there are situations where this is not feasible (e.g. when OpenStack is under management of an orchestrator).
We have a request to setup Designate to register all machines that are connected to a self-service network. That deployment is using BGP to advertise that SSN.
On a particular customer, we have the following configuration set:
Neutron-api: https:/
Please, check that vni_ranges jump on one value, that was necessary to make the SSN available to Designate, as described on: https:/
Nova-cloud-
Neutron-Gateway: https:/
Neutron-
description: | updated |
Changed in charm-neutron-gateway: | |
status: | New → Triaged |
Changed in charm-neutron-gateway: | |
status: | In Progress → Fix Released |
Changed in charm-neutron-api: | |
status: | In Progress → Fix Committed |
Changed in charm-nova-cloud-controller: | |
status: | In Progress → Fix Committed |
Changed in charm-neutron-api: | |
status: | Fix Committed → Fix Released |
Changed in charm-nova-cloud-controller: | |
status: | Fix Committed → Fix Released |
Changed in charm-nova-compute: | |
status: | In Progress → Fix Committed |
Changed in charm-nova-compute: | |
status: | Fix Committed → Fix Released |
Changed in charm-nova-compute: | |
status: | Fix Released → Triaged |
Changed in charm-nova-compute: | |
status: | Triaged → Fix Released |
Marking as Field Critical as I'm facing a deployment on a customer that is exactly on the Guest OS/orchestrator situation described above.