Bug 1871104
Summary: | If PXE provision source is selected on a cluster without a NAD available, dont let the user continue | ||
---|---|---|---|
Product: | OpenShift Container Platform | Reporter: | Tomas Jelinek <tjelinek> |
Component: | Console Kubevirt Plugin | Assignee: | Yaacov Zamir <yzamir> |
Status: | CLOSED ERRATA | QA Contact: | Guohua Ouyang <gouyang> |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | 4.6 | CC: | aos-bugs, gouyang, mcarleto, yzamir |
Target Milestone: | --- | ||
Target Release: | 4.6.0 | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | ux_issue | ||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2020-10-27 16:30:14 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
Tomas Jelinek
2020-08-21 10:45:05 UTC
can you please provide some quick design on where and how the warning should look like Please have a look at this design I've put together https://docs.google.com/document/d/1TNIVVxhL5REgu_TbdZ61tJV-Lj2bkZiJqm0wRh7l8qc/edit# 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. 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 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? moving out until there is a ltgm on the pr pr got lgtm @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. 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 Thanks Yaacov. Move the bug to verified. 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 The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days |