search

UpstreamDataInc / goosebit

A simplistic, opinionated remote update server implementing hawkBit™'s DDI API.
https://goosebit.rtfd.io
Apache License 2.0
12 stars 2 forks source link

Roadmap #25

Closed b-rowan closed 5 days ago

b-rowan commented 1 month ago

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

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

tsagadar commented 1 month 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.

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

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 week ago

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 commented 5 days ago

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