Bug 1871104 - If PXE provision source is selected on a cluster without a NAD available, dont let the user continue [NEEDINFO]
Summary: If PXE provision source is selected on a cluster without a NAD available, don...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Console Kubevirt Plugin
Version: 4.6
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 4.6.0
Assignee: Yaacov Zamir
QA Contact: Guohua Ouyang
URL:
Whiteboard: ux_issue
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-08-21 10:45 UTC by Tomas Jelinek
Modified: 2021-02-08 12:08 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-10-27 16:30:14 UTC
Target Upstream Version:
tjelinek: needinfo? (mcarleto)


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github openshift console pull 6554 0 None closed Bug 1871104: PXE requires NADs 2021-02-08 12:07:09 UTC
Red Hat Product Errata RHBA-2020:4196 0 None None None 2020-10-27 16:30:29 UTC

Description Tomas Jelinek 2020-08-21 10:45:05 UTC
Description of problem:

On a cluster without a newtwork attachment definition, it is not possible to use a PXE boot. Yet the user can pick it and get lost.

The ask is to provide a warning right in the first screen blocking the user from continuing to the next screen. The warning needs to explain that a new network attachment definition needs to be created in this namespace and that the administrator needs to be contacted to do it.

Comment 1 Tomas Jelinek 2020-08-21 10:46:36 UTC
can you please provide some quick design on where and how the warning should look like

Comment 2 Matt 2020-08-22 12:51:33 UTC
Please have a look at this design I've put together
https://docs.google.com/document/d/1TNIVVxhL5REgu_TbdZ61tJV-Lj2bkZiJqm0wRh7l8qc/edit#

Comment 3 Matt 2020-08-22 13:09:40 UTC
A follow up question:
Should we be blocking the user from creating the VM? Could we allow the user to create the VM, then create the NAD and then the VM would start successfully? 
We could notify them that they will need to create a PXE NAD after the VM has been created before it can start successfully. Feels more K8s to me.

Comment 4 Yaacov Zamir 2020-08-27 12:07:05 UTC
we create boot devices when:

a - user choose os that has an image definition:
    we use a helper to create a boot device (disk clone) and set it to be the first boot device
b - user choose source to be URL or Container:
    we use a helper to create a boot device (disk clone) and set it to be the first boot device

in this cases we only show a gray info line under the input that tell the user we created ( or failed :-) ) a new boot device and they can see it in the storage tab.


> Should we be blocking the user from creating the VM? Could we allow the user to create the VM, then create the NAD and then the VM would start successfully? 

IMHO, in the case of source PXE we should use the same UX logic we use for source and os inputs, use a helper to try and create a boot device ( network ), 
and show a gray info line under the input that tell the user we created ( or failed :-) ) and they can see it in the network tab.

> We could notify them that they will need to create a PXE NAD after the VM has been created before it can start successfully. Feels more K8s to me.

In the case of failure to create a net device, we can be more dramatic and show a more scary info line to tell users to go talk to the cluster admin and tell them the network infrastructure on their cluster does not allow PXE boot

Comment 5 Matt 2020-08-27 14:54:42 UTC
please review this updated design here
https://xd.adobe.com/view/c2e37d75-696d-4a0b-901a-e8008326970e-97b0/
It required a NAD before the user can advance in the wizard and pushes them to contact their admin.
In the case where we CAN create the NIC using an existing NAD then we do it and advise them of it.
Are we missing anything here?

Comment 6 Tomas Jelinek 2020-09-24 06:44:56 UTC
moving out until there is a ltgm on the pr

Comment 7 Yaacov Zamir 2020-09-24 08:28:08 UTC
pr got lgtm

Comment 9 Guohua Ouyang 2020-09-29 06:42:51 UTC
@Tomas @Yaacov @Matt Should we provide a link to `Create Network Attachment Definition` form like the golden OS field does for image upload? So user can click link and be able to create the nad.

Comment 10 Yaacov Zamir 2020-09-29 07:32:08 UTC
Note:
answering comment #9 , unlike uploading disk images where users need permissions and a disk image, creating a NAD requires knowledge about the h/w running the cluster.

IMHO we should not provide a link to create NAD because it will not help users unless they have deep knowledge of the cluster infrastructure
another option discussed was to add a link to creating NADs documentation to let users know what they need to do/know to create a NAD:

https://docs.openshift.com/container-platform/4.5/networking/multiple_networks/understanding-multiple-networks.html

Comment 11 Guohua Ouyang 2020-09-29 08:18:29 UTC
Thanks Yaacov.
Move the bug to verified.

Comment 14 errata-xmlrpc 2020-10-27 16:30:14 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 (OpenShift Container Platform 4.6 GA Images), 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:4196


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