Description of problem: Creates a VM template from the wizard and fills in cloud-init with hostname and ssh key, it creates a template with cloud-init like below, it has a redundant hostname(2nd) out of the cloud-init block, which will cause VM failing to set its hostname. ----------------------------------------- - name: cloudinitdisk cloudInitNoCloud: userData: | #cloud-config users: - name: default ssh-authorized-keys: >- ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCj47ubVnxR16JU7ZfDli3N5QVBAwJBRh2xMryyjk5dtfugo5JIPGB2cyXTqEDdzuRmI+Vkb/A5duJyBRlA+9RndGGmhhMnj8and3wu5/cEb7DkF6ZJ25QV4LQx3K/i57LStUHXRTvruHOZ2nCuVXWqi7wSvz5YcvEv7O8pNF5uGmqHlShBdxQxcjurXACZ1YY0YDJDr3AJai1KF9zehVJODuSbrnOYpThVWGjFuFAnNxbtuZ8EOSougN2aYTf2qr/KFGDHtewIkzZmP6cjzKO5bN3pVbXxmb2Gces/BYHntY4MXBTUqwsmsCRC5SAz14bEP/vsLtrNhjq9vCS+BjMT hostname: fedoratest1234 hostname: fedoratest1234 ----------------------------------------- Version-Release number of selected component (if applicable): 4.3.0-0.nightly-2019-11-02-092336. How reproducible: 100% Steps to Reproduce: 1. Use VM template wizard 2. Use cloud-init 3. Create the template Actual results: Expected results: Additional info:
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