Bug 1770665 - VM wizard cannot use hostname in cloud-init as the VM hostname when using custom script
Summary: VM wizard cannot use hostname in cloud-init as the VM hostname when using cus...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Console Kubevirt Plugin
Version: 4.3.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 4.3.0
Assignee: Gilad Lekner
QA Contact: Nelly Credi
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-11-11 05:18 UTC by Guohua Ouyang
Modified: 2020-01-23 11:12 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-01-23 11:12:05 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github openshift console pull 3400 0 'None' closed Bug 1770665: Fix VM's hostname not being imported from cloud-init data 2020-04-23 11:14:42 UTC
Red Hat Product Errata RHBA-2020:0062 0 None None None 2020-01-23 11:12:18 UTC

Description Guohua Ouyang 2019-11-11 05:18:36 UTC
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:

Comment 1 Gilad Lekner 2019-11-11 14:49:47 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.

Comment 2 Gilad Lekner 2019-11-11 14:51:13 UTC
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.

Comment 3 Guohua Ouyang 2019-11-11 23:42:47 UTC
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.

Comment 4 Guohua Ouyang 2019-11-12 03:36:31 UTC
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.

Comment 5 Tomas Jelinek 2019-11-12 08:08:05 UTC
@Gilad: just for reference, this is how is it supposed to be working: https://bugzilla.redhat.com/show_bug.cgi?id=1688124#c10

Comment 6 Gilad Lekner 2019-11-13 13:58:35 UTC
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

Comment 7 Guohua Ouyang 2019-11-14 02:44:25 UTC
(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.

Comment 8 Gilad Lekner 2019-11-14 09:07:12 UTC
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?

Comment 9 Guohua Ouyang 2019-11-14 09:22:38 UTC
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.

Comment 10 Gilad Lekner 2019-11-14 10:23:31 UTC
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.

Comment 11 Guohua Ouyang 2019-11-18 03:13:30 UTC
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.

Comment 13 Guohua Ouyang 2019-12-10 06:04:25 UTC
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".

Comment 15 errata-xmlrpc 2020-01-23 11:12:05 UTC
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


Note You need to log in before you can comment on or make changes to this bug.