Closed b-rowan closed 5 days ago
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.
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.
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.
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.
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)
Things I have not yet fully understood / tested
Maybe best to combine the approach of mandating that devices report their installed version plus using a firmware_id as the action_id?
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?
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?
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.
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.
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.
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.
As we moved roadmapping to use milestones, this issue can be closed.
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
[x] #70
Stability Improvements
action_id
usage[x] Firmware upload behavior: deletes old firmware with same URI and linked devices/rollouts
Operational Improvements
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
Fixes / Minor Improvements
Enhanced Features Release (v0.4.0)
Extend gooseBit with additional functionality.
Features
Documentation