Asset OTA fixes #2711
Asset OTA fixes #2711
Conversation
avtolstoy
force-pushed
the
feature/asset-ota-fixes
branch
from
825113e to
b09475c
Compare
| if (!is_module_function_valid((module_function_t)module.info.module_function)) { | ||
| continue; | ||
| } | ||
| // If sending a describe, skip factory modules entirely just in case |
There was a problem hiding this comment.
This will be reverted once this is safe.
avtolstoy
force-pushed
the
feature/asset-ota-fixes
branch
from
b09475c to
ce04487
Compare
avtolstoy
force-pushed
the
feature/asset-ota-fixes
branch
2 times, most recently
from
adc22ac to
6eaff5e
Compare
| pbDesc.assets.arg = (void*)&availableAssets; | ||
| pbDesc.assets.funcs.encode = encodeAssetDependencies; | ||
| } | ||
| EncodeAssets assets(&pbDesc.assets, AssetManager::instance().availableAssets()); |
There was a problem hiding this comment.
I think this should use availableAndRequiredAssets() to avoid showing assets still on the device but not required by the application on the Console.
There was a problem hiding this comment.
This is for cloud: we want the DS to be aware of what is entirely on the device to avoid OTAing things over unnecessarily.
There was a problem hiding this comment.
As discussed before the "use-case" for this is:
- product fw version 1 assets (1,2,3)
- product fw version 2 assets (2,3)
- product fw version 3 assets (1,2,3)
Currently apart from the product application OTA (and depending on whether Device OS upgrade happened of course) the assets in this particular case will not get OTAd at all post #1.
There was a problem hiding this comment.
Assets wouldn't get flashed unnecessarily if this used availableAndRequiredAssets() either since after 1, it would return assets 1, 2, 3 available, after 2, it would return 2, 3 available and after 3, it would return 1, 2, 3. The OTA planner only triggers after the device sends the new describe message. But since it works both ways it's fine like this.
| int getAssetInfo(ctrl_request* req) { | ||
| PB(GetAssetInfoReply) pbRep = {}; | ||
| using namespace particle::system; | ||
| EncodeAssets assetsAvailable(&pbRep.available, AssetManager::instance().availableAssets()); |
There was a problem hiding this comment.
Similarly I think this should use availableAndRequiredAssets() for consistency with the describe and Wiring API. The CLI flashes the new application before assets so returning available and required assets in the control request will work.
There was a problem hiding this comment.
I'd disagree. I'd like for system describe and control requests to represent the full picture and for wiring APIs to be representative of what's required by the application. Again, same thing: to avoid re-flashing things unnecessarily that are already on the device.
avtolstoy
force-pushed
the
feature/asset-ota-fixes
branch
from
c784a99 to
7c32b65
Compare
Description
This PR introduces a number of Asset OTA related fixes/enhancements:
CTRL_REQUEST_GET_ASSET_INFOcontrol request to fetch information about required/available assets on device over BLE/USBCTRL_REQUEST_GET_MODULE_INFOrefactored to align with new protobuf-based System Describe and encoding for both the control request and system describe coalesced into a single implementation to save on flash spaceSystem.assetsAvailable()hides extra assets that might still be in storage but are not currently required, essentially this is nowavailable ∩ requiredseek()forward and backwards support in wiring Asset OTA APIsTesting
ota/assetsNOTE: Requires latest
@particle/device-os-test-runnerRelated