Dasharo
Add scripts and/or processes for preparing servers with Dasharo firmware for testing DTS.
The problem you're addressing (if any)
When we do not have the needed Dasharo firmware images on public servers (dl.dasharo.com and dl.3mdeb.com) we have to manually figure out some workarounds.
Describe the solution you'd like
A script for automatic set up of a HTTP server with the same structure ad dl.3mdeb.com for DTS firmware access testing. A dev MinIO instance that will be easy to use for DTS firmware access testing using test DPP credentials.
Where is the value to a user, and who might that user be?
This will decrease time needed for testing of DTS features and eliminate risks of modifying production instances.
Describe alternatives you've considered
No response
Additional context
We have developed a manual instruction how to set up a dev instance of dl.3mdeb.com locally:
Setting up local firmware server
Prior to the release, it might happen that firmware binaries are not yet released on the default server, yet the DTS functionality must be verified. The solution is to set up a local firmware server.
To set up local firmware server you must create the same structure locally as it is on the remote. DTS checks out the firmware names only by path and name, thus it is possible to take any matching binaries and rename them so they match release version name.
Let's showcase this on an example.
(venv) user in ~/Downloads/fake_server λ tree . -L 5
.
└── novacustom_v5x0_mtl
├── novacustom_mtl_dgpu
│ ├── novacustom_v540tnx_mtl
│ │ └── uefi
│ │ ├── v1.0.0
│ │ └── v1.0.0-rc7.zip
│ └── novacustom_v560tnx_mtl
│ └── uefi
│ ├── v1.0.0
│ └── v1.0.0-rc7.zip
└── novacustom_mtl_igpu
├── novacustom_v540tu_mtl
│ └── uefi
│ ├── v1.0.0
│ └── v1.0.0-rc7.zip
└── novacustom_v560tu_mtl
└── uefi
├── v1.0.0
└── v1.0.0-rc7.zip
The above tree output shows that the latest at the time rc7 firmware binaries were unpacked ad v1.0.0 to spoof DTS. This way target paths didn't have to be modified. The DTS will attempt to flash those binaries. As long as the firmware is right for the target platform, there should be no issues.
To run the server, simply enter the directory and run the following
python -m http.server 8080
...then from the dts-shell set up the following variable to use your self-hosted server.
export FW_STORE_URL_DEV="http://<your_ip_addr>:8080"
@BeataZdunczyk, this is a good to solve issue for the next DTS release with new firmware support.
This to me seems like workarounding a process issue. Ideally, we would have an internal and a public instance/directories and just sync the internal to the public on release. We could then have some overwrite in DTS, that if pre-relase would use RCs.
What I'm afraid of is, we'll introduce this workaround and do that dance forever.
