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.
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