Bug 1770665
Summary: | VM wizard cannot use hostname in cloud-init as the VM hostname when using custom script | ||
---|---|---|---|
Product: | OpenShift Container Platform | Reporter: | Guohua Ouyang <gouyang> |
Component: | Console Kubevirt Plugin | Assignee: | Gilad Lekner <glekner> |
Status: | CLOSED ERRATA | QA Contact: | Nelly Credi <ncredi> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 4.3.0 | CC: | aos-bugs, glekner, gouyang, tjelinek |
Target Milestone: | --- | ||
Target Release: | 4.3.0 | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2020-01-23 11:12:05 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: |
Description
Guohua Ouyang
2019-11-11 05:18:36 UTC
I'm trying to debug this. When I fill a VM Template with cloudinit here is the output YAML { ... cloudInitNoCloud: userData: | #cloud-config name: default ssh-authorized-keys: - >- AAAAB3NzaC1yc2EAAAADAQABAA.... hostname: fed123 hostname: '${NAME}' ... } the 2nd hostname is null it seems The weird thing is that creating a VM from this template runs successfully with no errors. Will update again. Guohua, can you create a VM from the bugged template or not at all? Its worth mentioning that both VM and VMT wizards are outputting the same cloudinitdisk data, so the problem is in the VM/VMT creation outside this scope. Create VM from the template is no problem, the weird thing is that VM hostname is not set to the one as cloud-init data specifys. Remove the redundant line(2nd hostname), and use it to create VM, then the VM hostname can be set. ah, I found the root cause is the VM wizard didn't use the template's hostname ".spec.spec.template.domain.hostname", instead, it's using the vm name as its hostname. I tested that processing the template in cli like `oc process ccc -p NAME=test123 | oc create -f -`, and use it to create the VM, the VM has correct hostname. So it's the vm wizard issue, it didn't pick up the hostname from template. @Gilad: just for reference, this is how is it supposed to be working: https://bugzilla.redhat.com/show_bug.cgi?id=1688124#c10 so the template's hostname: `${NAME}` is the correct state? guohua If you can point me to where in the code you see the misuse: ".spec.spec.template.domain.hostname" it would be great (In reply to Gilad Lekner from comment #6) > so the template's hostname: `${NAME}` is the correct state? guohua yes, it's correct. > If you can point me to where in the code you see the misuse: > ".spec.spec.template.domain.hostname" it would be great I've been in the wrong direction. The root issue is the VM can only have a correct hostname when ".spec.spec.template.domain.hostname" is set in VM yaml. On VM wizard, if not using a custom script, the "Hostname" field in cloud-init section is used as the VM ".spec.spec.template.domain.hostname", so the VM will have the correct hostname. If use a custom script, the VM "Name" field will be used as the VM ".spec.spec.template.domain.hostname", so the VM gets a hostname from VM name, not from the cloud-init. Hey Again, In my ENV, when creating a VM from template or from scratch, ".spec.spec.template.domain.hostname" is using the VM's name and not the cloud-init's hostname. So at your environment only the custom script method is using the WRONG hostname? could you provide me with a valid script for testing? just to make sure, when cloudinitdata is provided, the ".spec.spec.template.domain.hostname" should always use the cloud-init hostname, right? My console version is 4.3.0-0.nightly-2019-11-02-092336 as it's reported in the bug, It's outdated but I don't have a new env to catch up the new version at the moment. If ".spec.spec.template.domain.hostname" is using the VM's name as you said, it might be a new issue on the latest version. It's supposing to be the same with cloud-init "Hostname", both in VM wizard and VM template wizard. For this issue, it's that when using a custom script, there is no "Hostname" field in cloud-init section anymore, and the wizard could not use the hostname in the custom script, so it's using the VM name. However, as we're using cloud-init, so the VM hostname should be the one specified by cloud-init, not the VM name from UI. Ok After talking with @Guohua on Bluejeans we figured out there are 2 bugs 1. Templates with cloud-init has a blank hostname : `${NAME}` instead of the cloud-init's hostname 2. VM's created from scratch with cloud-init OR template with cloud-init has the hostname set to the VM's name instead of the cloud-init's hostname Tomas I think we should close this open 2 new bugs. We need to make sure the two tabs(form and advance) can set the VM hostname via cloud-init's hostname, not the VM's name. Verified on 4.3.0-0.nightly-2019-12-04-054458. Using or without using template: the VM hostname can be initialized in both tab "form" and "custom script". 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, 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-2020:0062 |