-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Initial confirmationBase implementation #165
base: master
Are you sure you want to change the base?
Conversation
Any feedback on it so far? |
@UVV-gh Many thanks for your work on this! Unfortunately, I have not had time yet to play around with this new hawkbit feature to understand better how well your approach already fits and what is still missing, but what I have looked through looks very promising. 👍 I'd be interested in feedback from others who have an actual use case for this. (My personal 'use case' so far would just be a demo). |
Signed-off-by: Vyacheslav Yurkov <[email protected]>
When enabled, the polling uses confirmationBase end point of Hawkbit. Signed-off-by: Vyacheslav Yurkov <[email protected]>
Signed-off-by: Vyacheslav Yurkov <[email protected]>
Signed-off-by: Vyacheslav Yurkov <[email protected]>
Signed-off-by: Vyacheslav Yurkov <[email protected]>
Initial implementation of Hawkbit's confirmationBase end point. This version allows to send a request to a custon user backend/software, which is supposed to implement RaucInstallConfirmation DBus interface and be capable to make a decision whether an installation of new version is possible/desired at the moment and accept or decline it. See https://eclipse.dev/hawkbit/rest-api/rootcontroller-api-guide.html#_get_tenantcontrollerv1controlleridconfirmationbase for more into on the API end point. Signed-off-by: Vyacheslav Yurkov <[email protected]>
Signed-off-by: Vyacheslav Yurkov <[email protected]>
df3b3fc
to
b23138f
Compare
Fixed 10 seconds is used to stop waiting for a confirmation. This is done to avoid deadlock when a new confirmation request comes and the client's plugin needs more time to process the request. Signed-off-by: Vyacheslav Yurkov <[email protected]>
Signed-off-by: Vyacheslav Yurkov <[email protected]>
Signed-off-by: Vyacheslav Yurkov <[email protected]>
b23138f
to
655f937
Compare
Instead of providing the default "denied" we keep the confirmation request open. Signed-off-by: Vyacheslav Yurkov <[email protected]>
|
There's is a use case for this functionality in a product I'm developing right now, I'll try to add it to my client app software and make a review. It can take a bit of time though. |
Reminder to take a look at it :) @ejoerns @Bastian-Krause |
Roast me 😼
This is a first round of confirmationBase end-point implementation, see more discussions on that in this thread.
The workflow assumes that confirmation can be issued much later than requested, therefore a fixed 5 seconds timeout is used to check whether it was actually issued (in case of a daemon). I believe with more testing a better approach might be implemented. In case of "run once" the main thread simply waits for the confirmation.
What is not there yet, but should be added to improve the functionality:
Let me know what you think.