-
Notifications
You must be signed in to change notification settings - Fork 55
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
feat: add an option to use c8y operation ID to update its status #3076
feat: add an option to use c8y operation ID to update its status #3076
Conversation
Codecov ReportAttention: Patch coverage is Additional details and impacted files📢 Thoughts on this report? Let us know! |
Robot Results
|
4814b7a
to
e366d50
Compare
cd275db
to
5e95aa0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will be really happy to merge this PR. I just have one question.
/// Switch using 501-503 (without operation ID) or 504-506 (with operation ID) SmartREST messages for operation status update | ||
#[tedge_config(example = "true", default(value = true))] | ||
with_operation_id: bool, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What will be the behavior if operation ids are enabled on the device but not available on the c8y instance? Would things work? If not how the user will be notified? By error messages or stuck operations?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What will be the behavior if operation ids are enabled on the device but not available on the c8y instance? Would things work?
No, it won't work (that's we want to improve with auto
option)
If not how the user will be notified? By error messages or stuck operations?
I can't really test it since all tenants available for us are already 10.18 or above. User will definitely receive an error message on c8y/s/e
for unknown static template like below.
[c8y/s/us] 900
[c8y/s/e] 40,900,No static template for this message id
In this case, operation will be executed and successful/failed in thin-edge, but the status will stay PENDING
in c8y.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the plan to implement auto
detection? Can we probe for errors on c8y/s/e
when sending 504-506
messages and then fallback to the previous API?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the plan to implement auto detection? Can we probe for errors on c8y/s/e when sending 504-506 messages and then fallback to the previous API?
Definitely it's one of the doable options. We have similar issue for Advanced Software Management (requirement: 10.14> and dedicated Microservice). I want to have a consistent solution for this and Advanced Software Management. Probably we need to discuss Device Management Team to choose the best solution.
tests/RobotFramework/tests/cumulocity/software_management/software.robot
Show resolved
Hide resolved
tests/RobotFramework/tests/cumulocity/software_management/software.robot
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
fail_operation("505", op_id, reason) | ||
} | ||
|
||
fn fail_operation(number: &str, operation: &str, reason: &str) -> String { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fn fail_operation(number: &str, operation: &str, reason: &str) -> String { | |
fn fail_operation(template_id: &str, operation: &str, reason: &str) -> String { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Addressed all your renaming suggestion in this commit: 2e15950
|
||
/// Switch using 501-503 (without operation ID) or 504-506 (with operation ID) SmartREST messages for operation status update | ||
#[tedge_config(example = "true", default(value = true))] | ||
with_operation_id: bool, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
with_operation_id: bool, | |
direct_operation_update: bool, |
Not fully happy about this suggestion either. Accept only if you're convinced.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The key will look c8y.smartrest.direct_operation_update
. I don't think what "direct" means is so clear. At least, not for me. How about something in between my proposal and yours, c8y.smartrest.operation_id_update
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My bikeshed take would be something like c8y.smartrest.operation_explicit_id
or operation_template_explicit_id
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see no reason to change anything here: with_operation_id
is simple and clear.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, direct
isn't very clear. I kinda liked operation_explicit_id
as well. How about something even more direct: use_operation_id
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I vote +1 for use_operation_id
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approved
Cumulocity 10.18 version added 504-506 SmartREST static templates, which enables users to update operation status with its operation ID. Add a new tedge config to switch either 501-503 or 504-506 for operation status updates. Signed-off-by: Rina Fujino <[email protected]>
Signed-off-by: Rina Fujino <[email protected]>
0136b9e
to
e53921c
Compare
Proposed changes
Cumulocity 10.18 version added 504-506 SmartREST static templates, which enables users to update operation status with its operation ID. This PR adds a new tedge config to switch either 501-503 or 504-506 for operation status updates.
One can change the setting by
tedge config
.true
(504-506),false
(501-503). Ideally makingauto
option, however, this is out of scope of this PR.Note: for the naming decision, see this thread.
This change excludes the supports for below since they react to SmartREST operation messages, not JSON over MQTT. This means it's not possible to take its operation ID. Also, we don't generate thin-edge commands for these operations.
Types of changes
Paste Link to the issue
#2616
Checklist
cargo fmt
as mentioned in CODING_GUIDELINEScargo clippy
as mentioned in CODING_GUIDELINESFurther comments