DOCS-3434: Document Micro-RDK OTA updates

[JessamyT]

No description provided.

[netlify]

✅ Deploy Preview for viam-docs ready!

Name	Link
🔨 Latest commit	594ac00
🔍 Latest deploy log	https://app.netlify.com/sites/viam-docs/deploys/67991424e91cc10008729695
😎 Deploy Preview	https://deploy-preview-3917--viam-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 26 (🟢 up 4 from production) Accessibility: 98 (no change from production) Best Practices: 92 (no change from production) SEO: 92 (no change from production) PWA: 70 (no change from production) View the detailed breakdown and full score reports

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[npentrel]

Requesting changes, see comment.

Also: What are your thoughts on placing the OTA info in the Deploy & Manage section under Update packages?

[npentrel]

According to the scope, I think this would be more accurate as:

Your device checks for configuration updates periodically. If the devices receives a configuration with the OTA service and a modified  version in it, the device downloads the new firmware to an inactive partition and restarts. When the device boots it will load the new firmware.

The main point being that the Micro-RDK does not download anything. The Micro-RDK isn't an executable, it's what the device firmwares are built from. This needs SME review though.

[mattjperez]

@npentrel yes that correction is more accurate; however I think in your comment you may have meant 'does not install anything' instead of 'does not download anything'.

It's an all-or-nothing process since it's similar to trying to swap engines while driving. At least currently, there is no direct way to roll-back to a previous firmware if you do a bad upgrade. It's very possible to update to broken firmware that can leave the device in a bad state where it needs to be reflashed entirely

[JessamyT]

Also: What are your thoughts on placing the OTA info in the Deploy & Manage section under Update packages?

1. I was thinking micro should live in micro land since it's a small bit of content and pretty much everything else about micro stuff is on that one page. We could move it to Deploy and Manage and link to it from the micro page though.
2. The Deploy packages page says "OTA" so maybe the top of that page should actually have a link to the micro stuff wherever it lives in case people search OTA and land there?
3. Update packages is, like deploy, largely about fragments, and micro OTA isn't, so it'd seem a bit odd to have the content there as opposed to just a link, I think? If we do want it there, the intro would need editing to be inclusive of this bit

[npentrel]

Also: What are your thoughts on placing the OTA info in the Deploy & Manage section under Update packages?

1. I was thinking micro should live in micro land since it's a small bit of content and pretty much everything else about micro stuff is on that one page. We could move it to Deploy and Manage and link to it from the micro page though.

I'm ok with that while it's as long as you add a notice on the update package page. We probably also need one on the deploy page.

Speaking in broader terms though, both the Deploy package and update package pages could be changed to have sections for viam-server and viam-micro-server. It depends on how people think about deploying firmware. We could even add a subpage that is "Deploy firmware" and "Update firmware (OTA)".

2. The Deploy packages page says "OTA" so maybe the top of that page should actually have a link to the micro stuff wherever it lives in case people search OTA and land there?

At least a note, probably.

3. Update packages is, like deploy, largely about fragments, and micro OTA isn't, so it'd seem a bit odd to have the content there as opposed to just a link, I think? If we do want it there, the intro would need editing to be inclusive of this bit

I don't actually know if fragments are supported for Micro-RDK, I'll test it tomorrow. If it is, it may be worth having a conversation whether we suggest using fragments for the ota service

[mattjperez]

I don't actually know if fragments are supported for Micro-RDK, I'll test it tomorrow. If it is, it may be worth having a conversation whether we suggest using fragments for the ota service

@npentrel They are and are actually how we are configuring (both components and OTA service) the in-office temperature sensors

[mattjperez]

Also, @JessamyT, I'm not sure where, but we should put a large disclaimer about how any custom firmware is hosted

As of now, there are two hard requirements for properly hosting firmware:

1. the hosting endpoint must use HTTP/2

• GCP Buckets have this, but other blob storage solutions do not (such as AWS S3, GitHub Artifacts, etc). However, all major cloud providers have CDN options that provide HTTP/2 endpoints

2. the hosting endpoint must not use redirection

• we have a ticket for handling redirection, but unclear when that will be prioritized.

[JessamyT]

@npentrel okay this section has gotten a bit longer with the added tips so it's almost big enough to be a sub-page at this point. I would be fine with this moving over to there, and having a link from the micro page to where this content lands in /manage/. I'd err on the side of merging this sooner rather than later though since it's an exciting new update, and then if you decide it makes more sense in your section, editing those intros, descriptions etc. and moving it can happen in a subsequent PR?

In the meantime, I've added notes to deploy and to update, and I think I've addressed all the points you brought up Matt though if more details are needed, happy to add.

[npentrel]

I need to think some more about whether I think this should or should not move to the manage page, but good to merge for now and I'll make a follow up ticket for myself

[mattjperez]

LGreatTM!

[github-actions]

🔎💬 Inkeep AI search and chat service is syncing content for source 'Viam Docs (https://docs.viam.com)'