Bug 1872314
Summary: | [OSP 16.1] Can't launch instance if name contain '.' | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat OpenStack | Reporter: | mxie <mxie> | ||||||
Component: | openstack-nova | Assignee: | Stephen Finucane <stephenfin> | ||||||
Status: | CLOSED ERRATA | QA Contact: | OSP DFG:Compute <osp-dfg-compute> | ||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | high | ||||||||
Version: | 16.1 (Train) | CC: | chhu, dasmith, eglynn, igallagh, jamsmith, jhakimra, jmelvin, jparker, juzhou, kchamart, ljozsa, lyarwood, mzhan, nweinber, pkesavar, sbauza, sgordon, smooney, stephenfin, tyan, tzheng, vromanso, xiaodwan, zili | ||||||
Target Milestone: | z6 | Keywords: | Reopened, Triaged | ||||||
Target Release: | 16.1 (Train on RHEL 8.2) | ||||||||
Hardware: | x86_64 | ||||||||
OS: | Unspecified | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | openstack-nova-20.4.1-1.20201114041750.el8ost | Doc Type: | Bug Fix | ||||||
Doc Text: |
When an instance is created, the Compute (nova) service sanitizes the instance display name to generate a valid host name when DNS integration is enabled in the Networking (neutron) service.
+
Before this update, the sanitization did not replace periods ('.') in instance names, for example, 'rhel-8.4'. This could result in display names being recognized as Fully Qualified Domain Names (FQDNs) which produced invalid host names. When instance names contained periods and DNS integration was enabled in the Networking service, the Networking service rejected the invalid host name, which resulted in a failure to create the instance and a HTTP 500 server error from the Compute service.
+
With this update, periods are now replaced by hyphens in instance names to prevent host names being parsed as FQDNs. You can continue to use free-form strings for instance display names.
|
Story Points: | --- | ||||||
Clone Of: | |||||||||
: | 1919855 (view as bug list) | Environment: | |||||||
Last Closed: | 2021-05-26 13:49:37 UTC | Type: | Bug | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Bug Depends On: | 1919855 | ||||||||
Bug Blocks: | |||||||||
Attachments: |
|
Description
mxie@redhat.com
2020-08-25 13:36:57 UTC
Created attachment 1712539 [details]
instance-name-end-with-number.png
Created attachment 1712540 [details]
nova-compute.log
I've updated the title as this isn't related to the instance being spawned from a virt-v2v based volume, only that the name ends with a digits and this breaks one of our requests to neutron. The problem is that Nova passes the VM name to Neutron's dns_name port field, and if the VM name contains a period, Neutron will think everything after the period is a TLD code. In this case, it thinks 'ubuntu18.04' is a FQDN equivalent to redhat.com, with 'ubuntu18' playing the part of 'redhat', and '04' playing the part of 'com'. However, all-numeric TLD codes aren't allowed, so Neutron refuses. We can't just add this validation to Nova, because for instances without ports, or any other use case where the port's dns_name is not set to the VM's name, it's perfectly valid to have a VM called 'ubuntu18.04'. Because this is an edge case, and the impact is fairly minor, and there's no customer case, and of the limited capacity of the Compute DFG (us!), I want to be brutally honest and close this as WONTFIX. I agree it's not great UX, but we have to pick our battles, and we have others that have much greater impact. Cheers! Just got a customer request for this bug fix, see attached case. Customer said - Can we please get this escalated and placed onto priolist? sent email to rhosp-prio list following process. Also just reproduced on 16.1.2 lab env to confirm this fails for any attempt to create a VM name ending in .# $ openstack server create --image $image --nic net-id=$privnet --flavor $flavor --key-name $keypair --security-group $secgroup allang-vm.1 (overcloud) [stack@undercloud-0 ~]$ openstack server list +--------------------------------------+-------------+--------+-----------------------------------------+--------+--------+ | ID | Name | Status | Networks | Image | Flavor | +--------------------------------------+-------------+--------+-----------------------------------------+--------+--------+ | 81cc0485-6e21-4ca1-aab4-bb560b1806e8 | allang-vm.1 | ERROR | | cirros | | FYI, just confirmed it did used to work in RHOSP 13, test in lab running 13.0.12: $ openstack server create --image $image --nic net-id=$privnet --flavor $flavor --key-name $keypair --security-group $secgroup allang-vm.1 (overcloud) [stack@undercloud-0 ~]$ openstack server list +--------------------------------------+-------------+--------+-----------------------------------------+--------+-------------+ | ID | Name | Status | Networks | Image | Flavor | +--------------------------------------+-------------+--------+-----------------------------------------+--------+-------------+ | 1e5a574f-7566-4274-a057-68151b9b4c74 | allang-vm.1 | ACTIVE | allang-privnet=172.16.1.152 | cirros | allang-tiny | Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Red Hat OpenStack Platform 16.1.6 bug fix and enhancement advisory), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2021:2097 |