Description of problem: I'm testing the Assisted Service with Dell PowerEdge R340 hardware and the IDrac Virtual Media feature (firmware version 4.40.00.00) and try to specify the ISO download URL from the infraenv resource as the "Image File Path" in the IDRAC Virtual Media UI. An example for such a URL would be http://assisted-service-assisted-installer.apps.cluster-05.ocp.lab.eng.rdu2.redhat.com/api/assisted-install/v1/clusters/9d2d4aa8-8edd-4f79-97dc-219bafd7c6dc/downloads/image IDrac refuses that URL with > RAC0720: Unable to locate the ISO/IMG image in the network share because the > file path provided or the user credentials provided may be incorrect. Ensure > that you provide the correct file path and user credentials and retry the > operation Downloading the ISO file to an webserver and renaming it <something>.iso works and the servers boot properly. This prevents direct download of the ISO from the Assisted Server instance and causes an additional manual step in the installation process. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Install the Assisted Service 2. Create an Clusterdeployment and an InfraEnv resource 3. pick up the ISO download URl from the InfraEnv status 4. Try and enter the URL in an IDRAC virtual media UI Actual results: ISO URL refused by IDRAC (error message see above) Expected results: IDRAC accepts the URL Additional info: It would appear that changing the IDRAC behaviour is a lost cause, the best way forward seems to be adapt the URL format to conform with Dell IDRAC requirements
Hitting the same issue, it's blocking the ZTP deployment efforts on Dell when disabling ironic caching. Disabling the Ironic cache is important for cases when the ips of the masters are not reachable by the redfish endpoint, while reaching the AI service is easier because it can just be exposed to the outside. So this bug is quite a high priority one. Maybe an easy way to solve it is to implement some kind of url shortener, where AI generates some kind of http://<assisted_service_domain>/download/<random_id>.iso, that will translate to the real download endpoint.
Not sure literally shortening is ideal since it could potentially lower the entropy needed for authorization from the level currently set by the JWT signature to the length of the shortening token. Also requires implementing a shortener which is not trivial. Maybe we could somehow add a new API endpoint for ISO download that accepts the JWT token as part of the path of the URL rather than the parameters of the URL.
Here hitting the same issue: image: format: live-iso url: https://assisted-service-assisted-installer.apps.mgmt-hub.e2e.bos.redhat.com/api/assisted-install/v1/clusters/d159a889-5677-4c55-bd04-74ca2e2e1942/downloads/image?api_key=eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJjbHVzdGVyX2lkIjoiZDE1OWE4ODktNTY3Ny00YzU1LWJkMDQtNzRjYTJlMmUxOTQyIn0.LLNuZN0bnf_sUdKcEIK7FQFRI0U_sNuTWtOhomwbSlOwWCsFG_uvMaA56ENxRZWSPuuBuiLx9R-wwk9DApyjuw online: true status: errorCount: 1 errorMessage: 'Image provisioning failed: Failed to deploy. Exception: HTTP POST https://[2620:52:0:1300::34]/redfish/v1/Managers/iDRAC.Embedded.1/VirtualMedia/CD/Actions/VirtualMedia.InsertMedia returned code 400. Base.1.2.GeneralError: Unable to perform the insert operation because the image file https://assisted-service-assisted-installer.apps.mgmt-hub.e2e.bos.redhat.com/api/assisted-install/v1/clusters/d159a889-5677-4c55-bd04-74ca2e2e1942/downloads/image?api_key=eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJjbHVzdGVyX2lkIjoiZDE1OWE4ODktNTY3Ny00YzU1LWJkMDQtNzRjYTJlMmUxOTQyIn0.LLNuZN0bnf_sUdKcEIK7FQFRI0U_sNuTWtOhomwbSlOwWCsFG_uvMaA56ENxRZWSPuuBuiLx9R-wwk9DApyjuw is of a different type than the insert operation supported by CD. Extended information: [{''Message'': ''Unable to perform the insert operation because the image file https://assisted-service-assisted-installer.apps.mgmt-hub.e2e.bos.redhat.com/api/assisted-install/v1/clusters/d159a889-5677-4c55-bd04-74ca2e2e1942/downloads/image?api_key=eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJjbHVzdGVyX2lkIjoiZDE1OWE4ODktNTY3Ny00YzU1LWJkMDQtNzRjYTJlMmUxOTQyIn0.LLNuZN0bnf_sUdKcEIK7FQFRI0U_sNuTWtOhomwbSlOwWCsFG_uvMaA56ENxRZWSPuuBuiLx9R-wwk9DApyjuw is of a different type than the insert operation supported by CD.'', ''MessageArgs'': [''https://assisted-service-assisted-installer.apps.mgmt-hub.e2e.bos.redhat.com/api/assisted-install/v1/clusters/d159a889-5677-4c55-bd04-74ca2e2e1942/downloads/image?api_key=eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJjbHVzdGVyX2lkIjoiZDE1OWE4ODktNTY3Ny00YzU1LWJkMDQtNzRjYTJlMmUxOTQyIn0.LLNuZN0bnf_sUdKcEIK7FQFRI0U_sNuTWtOhomwbSlOwWCsFG_uvMaA56ENxRZWSPuuBuiLx9R-wwk9DApyjuw'', ''CD''], ''MessageArgs'': 2, ''MessageId'': ''IDRAC.1.6.SYS453'', ''RelatedProperties'': [''Image''], ''RelatedProperties'': 1, ''Resolution'': ''Do the following the retry the operation: 1) Check if the image file is valid and of support type. iDRAC supports only the .ISO files for CD and .IMG file for removable drive. 2) Check if the action is performed on the correct device.'',
Created attachment 1784009 [details] Issue loading image into iDrac
I'm going to call this one resolved by https://github.com/openshift/assisted-service/pull/1744. I've opened additional bugs to track more granular issues the service is having with serving an iso for use with virtual media. I don't think it makes sense to try to solve all of this with on bug. https://bugzilla.redhat.com/show_bug.cgi?id=1962651 https://bugzilla.redhat.com/show_bug.cgi?id=1962665