Bug 1688124 - The FQDN of VM is not correct on UI
Summary: The FQDN of VM is not correct on UI
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Container Native Virtualization (CNV)
Classification: Red Hat
Component: User Experience
Version: 1.4
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 2.0
Assignee: Phillip Bailey
QA Contact: Radim Hrazdil
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-03-13 08:12 UTC by Guohua Ouyang
Modified: 2019-07-24 20:16 UTC (History)
7 users (show)

Fixed In Version: 2.0.0-14.4
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-07-24 20:15:51 UTC
Target Upstream Version:


Attachments (Terms of Use)
fedora.yaml (1.71 KB, text/plain)
2019-03-13 08:12 UTC, Guohua Ouyang
no flags Details
fedora-pod.yaml (6.03 KB, text/plain)
2019-03-20 00:46 UTC, Guohua Ouyang
no flags Details
fedora-vmi.yaml (2.01 KB, text/plain)
2019-03-20 00:47 UTC, Guohua Ouyang
no flags Details


Links
System ID Priority Status Summary Last Updated
Github https://github.com/kubevirt web-ui-components pull 450 None None None 2019-11-27 11:51:33 UTC
Github kubevirt web-ui-components pull 392 'None' 'closed' 'Correct hostname display in VM overview tab' 2019-11-27 11:51:33 UTC
Red Hat Product Errata RHEA-2019:1850 None None None 2019-07-24 20:15:59 UTC

Description Guohua Ouyang 2019-03-13 08:12:23 UTC
Created attachment 1543517 [details]
fedora.yaml

Description of problem:
Create a VM with a hostname in the cloud-init section, once it's running, check the VM FQDN on overview page, the FQDN is the VM's name which is provided on UI, but not the hostname of the VM. 

Version-Release number of selected component (if applicable):
kubevirt-web-ui:v1.4.0-14.1

How reproducible:


Steps to Reproduce:
1. create a vm with a hostname in cloud-init.
2. start the vm
3. check vm FQDN on vm overview page

Actual results:
The FQDN is not the hostname.

Expected results:
The FQDN should be the vm's hostname.

Additional info:
The vm yaml is attached.

Comment 1 Tomas Jelinek 2019-03-19 11:26:19 UTC
Can you please also provide the vmi and the launcher pod yamls?

Comment 2 Guohua Ouyang 2019-03-20 00:46:21 UTC
Created attachment 1545863 [details]
fedora-pod.yaml

Comment 3 Guohua Ouyang 2019-03-20 00:47:03 UTC
Created attachment 1545864 [details]
fedora-vmi.yaml

The pod and vmi yaml are attached now.

Comment 4 Tomas Jelinek 2019-03-27 00:35:20 UTC
ok, first of all we should probably not call it in UI "fqdn" since it actually is "hostname".

But anyway, it looks like the hostname is not reported by the backend correctly.

@Fabian: any idea why is the hostname not reported correctly?

Comment 5 Fabian Deutsch 2019-03-27 08:58:14 UTC
Yes, it can only be about hostname, not FQDN. FQDN is a cluster assigned attribute.

cloud-init is a best effort, we cna not know ahead of time if it will be effective or not.

There is no paste or screenshot here which actually shows the UI contents. Thus I don't know what's shown there.
I also don't know what the UI is using to determine the hostname of the VM.

Today VMI.spec.hostname and cloud-init hostname are overlapping. The best way to set a hostname is to use VMI.spec.hstname https://kubevirt.io/api-reference/v0.15.0/definitions.html#_v1_virtualmachineinstancespec

Comment 6 Tomas Jelinek 2019-03-27 10:39:23 UTC
@Fabian, thank you for the quick answer, some more clarifications, questions:

1: In VM the object the cloud init sets the hostname to "test.example.com". That is what would we like to see in the UI. Instead we see "fedora".

2: We are using the pod.spec.hostname which in this case has the value: fedora. Should we not use that one?

3: There is no "hostname" field in "vmi" (at least in this case). Why would that be?

Comment 7 Fabian Deutsch 2019-03-27 10:41:44 UTC
> @Fabian, thank you for the quick answer, some more clarifications, questions:

This answer is quicker!

> 1: In VM the object the cloud init sets the hostname to "test.example.com". That is what would we like to see in the UI. Instead we see "fedora".

Right. understood. But that can not be achieved from the KubeVirt VM API, as cloud-init is a best effort.
Also, setting an FQDN should not be possible, as this does not necessarily man that the fqdn is reachable from outside of the vmi.

> 2: We are using the pod.spec.hostname which in this case has the value: fedora. Should we not use that one?

Yes

> 3: There is no "hostname" field in "vmi" (at least in this case). Why would that be?

VMI.spec.hostname, check this link (as in my previous comment) https://kubevirt.io/api-reference/v0.15.0/definitions.html#_v1_virtualmachineinstancespec

Comment 8 Tomas Jelinek 2019-03-27 10:54:11 UTC
(In reply to Fabian Deutsch from comment #7)
> > @Fabian, thank you for the quick answer, some more clarifications, questions:
> 
> This answer is quicker!

we are on fire today!

> 
> > 1: In VM the object the cloud init sets the hostname to "test.example.com". That is what would we like to see in the UI. Instead we see "fedora".
> 
> Right. understood. But that can not be achieved from the KubeVirt VM API, as
> cloud-init is a best effort.
> Also, setting an FQDN should not be possible, as this does not necessarily
> man that the fqdn is reachable from outside of the vmi.

understood, will rename to hostname.

> 
> > 2: We are using the pod.spec.hostname which in this case has the value: fedora. Should we not use that one?
> 
> Yes
> 
> > 3: There is no "hostname" field in "vmi" (at least in this case). Why would that be?
> 
> VMI.spec.hostname, check this link (as in my previous comment)
> https://kubevirt.io/api-reference/v0.15.0/definitions.
> html#_v1_virtualmachineinstancespec

I did...

To summarize: would the correct solution be to have a label called "hostname" and a value either the value of "vmi.spec.hostname" or "---" when the "hostname" is missing from the vmi.spec.hostname? e.g. given the example of the yamls in this BZ, we would show "---".

Comment 9 Fabian Deutsch 2019-03-27 11:19:25 UTC
 >To summarize: would the correct solution be to have a label called "hostname" and a value either the value of "vmi.spec.hostname" or "---" when the "hostname" is missing from the vmi.spec.hostname? e.g. given the example of the yamls in this BZ, we would show "---".

Yes, a UI field should set vmi.spec.hostname, and it can show whatever the UI shows if this field is emtpy.

Comment 10 Tomas Jelinek 2019-04-03 13:30:05 UTC
To make it very exact:

1: rename the "fqdn" to "hostname" UI
2: in new VM, if the cloud init is not used, set the VM's name into the vmi.spec.hostname
3: in new VM, if the cloud init is used, set the cloud-init hostname into the vmi.spec.hostname
4: show the vmi.spec.hostname as the VM's hostname, if it is set
5: show "---" if the vmi.spec.hostname is not set

Comment 11 Radim Hrazdil 2019-05-22 11:45:57 UTC
When I create the VM from YAML provided in attachments (which has hostname 'test.example.com' specified in cloud init), the vmi.spec.hostname is set to 'fedora' instead of 'test.example.com'.
Additionally, the VM Overview page displays dashes (---) instead of the value specified in vmi.spec.hostname.
Version: 2.0.0-14.5
Moving back to assigned.

Comment 12 Guohua Ouyang 2019-05-22 11:56:39 UTC
@rhrazdil, Create vm from cli, it will not set "spec.template.spec.hostname", so it's "---" on vm overview. 
Create vm from UI will set 'spec.template.spec.hostname', however, there is a new bug https://bugzilla.redhat.com/show_bug.cgi?id=1712725.

Comment 13 Radim Hrazdil 2019-05-22 14:22:47 UTC
@gouyang I'm not sure about 'spec.template.spec.hostname', Comment 10 mentions spec.hostname on VMI, and it does have a value set.
Therefore, according to Comment 10 number 4, it should be shown as VM hostname.

Comment 14 Guohua Ouyang 2019-05-23 00:38:02 UTC
@rhrazdil I didn't see vmi.spec.hostname is set when create the fedora vm from the attachment yaml. Create vm from yaml will not set that field unless you use the wizard.

Comment 15 Radim Hrazdil 2019-05-24 11:00:12 UTC
@guohua I see! I got confused with what is in the virt-launcher Pod and the VirtualMachineInstance manifest.
With this cleared up, I believe there is nothing blocking us from moving this one to verified.
version 2.0.0-15.5

Comment 17 errata-xmlrpc 2019-07-24 20:15:51 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/RHEA-2019:1850


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