Roadmap

[b-rowan]

As per #18, adding this separately so these should be able to be converted to issues independently, then closed nicely with PRs.

Basic Features Release (v0.2.0)

Basic features implemented. Can be deployed through docker.

Features

• UI support for rollouts #27
• CDN support for update files #28
• Prevent unnecessary initial updates
• Refine UI: firmware file name / firmware version / firmware compatibility - when to show what
• Remove unfinished "flavor" feature
• API access via token #70

Stability Improvements

• Allow semantic versioning
• Review action_id usage
• Improve memory management of UpdateManager #35
• Improve poll performance by reducing DB load #44
• Introduce automated testing
• Firmware upload behavior: deletes old firmware with same URI and linked devices/rollouts

Operational Improvements

• Add logging
• Add metrics #26
• Docker Support #31
• Add postgres support #54
• Database migrations #48

Quickstart Release (v0.3.0)

Lower the barrier to entry for new users by providing comprehensive documentation for both a quick start and a production-ready deployment of gooseBIt.

Documentation

• Reduce README.md, move content to Read the Docs.
• Getting started guide: explain steps to update a device.
• Production deployment steps

Fixes / Minor Improvements

• Support different (local) software with same file name #104

Enhanced Features Release (v0.4.0)

Extend gooseBit with additional functionality.

Features

• Rollout abort #43
• "Flavour" support #116
• Rollout stats/graph page #69

Documentation

• Contributors guide: how to change db schema, ...

[tsagadar]

To implement "Prevent unnecessary initial updates", have solid statistics for "Rollout abort" and to tick "Review action_id usage" we should find a conceptual agreement on how to track updates. Here some options I could imagine. Not really sure what the best approach is.

Only rely on device reporting "installed version"

gooseBit would mandate devices to report "installed_version". With this, it could easily prevent providing an outdated or no-op (same version) update to a device.

Downside: when feedback reports a successful update, it is not 100% clear if this is due to a manually assigned firmware or due to a rollout (as config could have changed in the meantime). Worse even for a failed update: it just has to be assumed that the currently matching config is what has failed. So a newly created rollout would update its statistics based on updates started with the previous rollout.

Use firmware_id as action_id

Introduce firmware DB table so that every firmware gets a unique identifier (use an always increasing PK). Provide this ID as the action_id when a device should install a firmware. This ensures, that device feedback can always be mapped to the firmware that was (tried to) install. So a newly created rollout won't get statistics attributed of updates that were in progress.

Downside: cannot prevent an initial no-op update. Not 100% clear if feedback relates to manually assigned firmware or rollout in case that config changed.

Use rollout_id as action_id

Idea: get rid of manually assigned updates, only support rollouts and use the rollout_id as action_id. So if single device should get specific update, create a rollout for a new feed and assign the device to the feed.

Downside: cannot prevent an initial no-op update. Somewhat limited user experience.

Create update_action for each update

Idea: before sending an available update to a device create an update_action record that captures device_id and firmware_id and has a PK. This PK can be used as the action id.

Downside: cannot prevent an initial no-op update. Becomes DB heavy (like hawkBit)

Open questions

Things I have not yet fully understood / tested

• Behavior of swupdate if update image has lower version number? What are the configuration options? Do we expect a certain configuration?
• Behavior of swupdate if update image has lower version number? What are the configuration options? Do we expect a certain configuration?

Proposal

Maybe best to combine the approach of mandating that devices report their installed version plus using a firmware_id as the action_id?

[easybe]

Another important topic is token-bases API access. We need to be able to create firmware entries and rollouts with our CI system. Is this already possible?

[b-rowan]

Another important topic is token-bases API access. We need to be able to create firmware entries and rollouts with our CI system. Is this already possible?

It should be, or at least should be simple enough to implement. I think right now it is just using a session cookie, but easy enough to have it sent in the header. What is your preference here on how to get/use that token?

[b-rowan]

Maybe best to combine the approach of mandating that devices report their installed version plus using a firmware_id as the action_id?

I have no clue what the best way to do this is, it's quite a complicated problem. I know you have been doing some work on rollouts though, so I'm willing to defer to your proposal here. Worst case scenario you find out it doesn't work the way you want and we have to change it, which I think is totally acceptable. This will be a learning experience in any case.

[easybe]

Another important topic is token-bases API access. We need to be able to create firmware entries and rollouts with our CI system. Is this already possible?

It should be, or at least should be simple enough to implement. I think right now it is just using a session cookie, but easy enough to have it sent in the header. What is your preference here on how to get/use that token?

Some user management, where a static token can be generated or a password can be set, would be great. The token would then be passed in a header. Normally basic auth is used for that, don’t know if and how it can be done with oauth.

[b-rowan]

Some user management, where a static token can be generated or a password can be set, would be great. The token would then be passed in a header. Normally basic auth is used for that, don’t know if and how it can be done with oauth.

Technically the token is already static PROVIDED a static SECRET value is set, since then it is just a JWT with the claim holding the username of the authenticated user. With the secret value being randomized on each startup this doesn't work though.

[tsagadar]

Updated roadmap with v0.3.0 and v0.4.0. Any opinions if this is the proper focus / order?

Currently I think it is hard for interested parties to quickly try out gooseBit. This is what I'd wanted to improve first.

[tsagadar]

As we moved roadmapping to use milestones, this issue can be closed.