Initial confirmationBase implementation#165
Open
UVV-gh wants to merge 11 commits intorauc:masterfrom
Open
Conversation
Contributor
Author
|
Any feedback on it so far? |
Member
|
@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). |
UVV-gh
force-pushed
the
feature/confirmation-base-ready
branch
from
df3b3fc to
b23138f
Compare
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
UVV-gh
force-pushed
the
feature/confirmation-base-ready
branch
from
b23138f to
655f937
Compare
Contributor
Author
|
|
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. |
Contributor
Author
|
Reminder to take a look at it :) @ejoerns @Bastian-Krause |
Signed-off-by: Vyacheslav Yurkov <uvv.mail@gmail.com>
When enabled, the polling uses confirmationBase end point of Hawkbit. Signed-off-by: Vyacheslav Yurkov <uvv.mail@gmail.com>
Signed-off-by: Vyacheslav Yurkov <uvv.mail@gmail.com>
Signed-off-by: Vyacheslav Yurkov <uvv.mail@gmail.com>
Signed-off-by: Vyacheslav Yurkov <uvv.mail@gmail.com>
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 <uvv.mail@gmail.com>
Signed-off-by: Vyacheslav Yurkov <uvv.mail@gmail.com>
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 <uvv.mail@gmail.com>
Signed-off-by: Vyacheslav Yurkov <uvv.mail@gmail.com>
Signed-off-by: Vyacheslav Yurkov <uvv.mail@gmail.com>
Instead of providing the default "denied" we keep the confirmation request open. Signed-off-by: Vyacheslav Yurkov <uvv.mail@gmail.com>
UVV-gh
force-pushed
the
feature/confirmation-base-ready
branch
from
e0df824 to
17035d5
Compare
Contributor
Author
|
Annual rebase @ejoerns ... ;) |
|
I respectfully request the developers to accept this feature! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.