Add delta support to orchestrator #1489
Conversation
The primary point of this change is that it re-enables firmware delta support. It also tries to alleviate the need for generating a ton of unused delta files. It tackles this by doing something that has already been discussed and which I think is generally agreed upon which is give the orchestrator the job of telling a newly connected device to update. That removes the instant update on connect. We could reintroduce a mechanism for the orchestrator to react to new devices if we like. When a device joins the channel it will report it's firmware version to the orchestrator. This gives the orchestrator the chance to fire off Oban jobs for new firmware deltas. At the same time it will store a list of firmware versions that have been processed or are processing. This alleviates the need for repeated lookups. Firmware versions that are in processing are excluded from registry lookups to distribute updates. When deltas are done generating the orchestrator will receive an event causing a refresh of the delta status state.
|
This can be the start of discussion. I think this approach would work. My biggest concern is really that I didn't find any Orchestrator tests? And that makes groking how it operates difficult. |
|
Yeah the orchestrator was created with a lot of nerves vms going and tested manually, along with the integration level of testing in This is all going to be rewritten very shortly anyways, it's my next step once we get #1476 in. There's a lot of people in smartrent that would like all of this queue shaped so that's what I was going to do next. I'm not sure if it makes more sense to get this in now or wait until after this has been rewritten 🤷 |
|
Here is where I think we need to coordinate. We have a lot of plans for deployments with NervesCloud and the health information from devices. If we actually synced up about what you are trying to do for SmartRent right now we could take a load off you and you from us potentially. Rather than what I think will happen now which is arguably working redundantly on the same stuff. |
|
@jjcarstens this is delta support for the current orchestrator, is this worth updating and getting done or should we be focusing on the new variant of firmware orchestration you think? |
The primary point of this change is that it re-enables firmware delta
support.
It also tries to alleviate the need for generating a ton of unused
delta files.
It tackles this by doing something that has already been discussed
and which I think is generally agreed upon which is give the
orchestrator the job of telling a newly connected device to update.
That removes the instant update on connect. We could reintroduce a
mechanism for the orchestrator to react to new devices if we like.
When a device joins the channel it will report it's firmware version
to the orchestrator. This gives the orchestrator the chance to fire
off Oban jobs for new firmware deltas. At the same time it will store
a list of firmware versions that have been processed or are
processing. This alleviates the need for repeated lookups.
Firmware versions that are in processing are excluded from registry
lookups to distribute updates.
When deltas are done generating the orchestrator will receive an
event causing a refresh of the delta status state.