Build on Testflinger support for file attachments (CERTTF-303) to introduce provisioning using a file attachment instead of downloading an image from a URL. In the scope of this PR this only applies to the muxpi device connector.
The file attachment to be used is specified in the new use_attachment field, provided as an alternative to the url field. Previously, url was required, now one of url or use_attachment are required.
Significant refactoring/reimplementation has taken place in this context: previously, downloading the image from the url, decompressing and flashing on the device media was entirely performed on the device connector using a series of pipes, roughly like this:
This was efficient and avoided saving the downloaded image file on the device connector (where storage is generally constrained). However, it also made logging and debugging difficult, as the whole process was consolidated, making it hard to distinguish which part failed.
In this PR, the process is initiated on the agent and is roughly performed like this:
The path here is the provisioning image, which has either been previously downloaded on the agent from a URL or is an attachment.
This unifies the process of transferring the image on the device connector and flashing it, regardless of the source of the image, and also allows for more fine-grained logging and debugging.
@boukeas Also, feel free to mark that comment resolved and merge it... I just put it there to make sure you saw it but it doesn't need to block merging :)
Description
Build on Testflinger support for file attachments (CERTTF-303) to introduce provisioning using a file attachment instead of downloading an image from a URL. In the scope of this PR this only applies to the
muxpi
device connector.The file attachment to be used is specified in the new
use_attachment
field, provided as an alternative to theurl
field. Previously,url
was required, now one ofurl
oruse_attachment
are required.Significant refactoring/reimplementation has taken place in this context: previously, downloading the image from the url, decompressing and flashing on the device media was entirely performed on the device connector using a series of pipes, roughly like this:
This was efficient and avoided saving the downloaded image file on the device connector (where storage is generally constrained). However, it also made logging and debugging difficult, as the whole process was consolidated, making it hard to distinguish which part failed.
In this PR, the process is initiated on the agent and is roughly performed like this:
The
path
here is the provisioning image, which has either been previously downloaded on the agent from a URL or is an attachment.This unifies the process of transferring the image on the device connector and flashing it, regardless of the source of the image, and also allows for more fine-grained logging and debugging.
Resolved issues
Linked to CERTTF-316.
Documentation
The section regarding attachments in the Testflinger reference has been updated.
Tests
All tests performed on the
rpi4b1g001
agent ontestflinger-staging
, with themuxpi
device connector installed from this branch.Provisioning from a URL
See result.
Provisioning from an attachment
See result.
Error cases: Provisioning without a URL or from a non-existent attachment
See result.
See result.