fix: c8y operation fragments for firmware/software update and device profile#3362
Conversation
450a075 to
ee5b094
Compare
ee5b094 to
845563f
Compare
845563f to
0bc67d4
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files📢 Thoughts on this report? Let us know! |
Robot Results
|
crates/extensions/c8y_mapper_ext/src/operations/handlers/software_update.rs
Show resolved
Hide resolved
crates/extensions/c8y_mapper_ext/src/operations/handlers/firmware_update.rs
Outdated
Show resolved
Hide resolved
|
The |
0bc67d4 to
9af954b
Compare
9af954b to
6f3e142
Compare
6f3e142 to
2ff567b
Compare
Updated the source ticket #3162 with some findings around the |
4aa42e7 to
28f7360
Compare
albinsuresh
left a comment
There was a problem hiding this comment.
Very close, but yet one step away.
As discussed offline, even after a successful application of the device profile, the config entries still appear with a "Not installed on the device" warning, despite sending the 120 message and replacing the proxy url with the tenant URL.
I investigated and understood why this is happening. Even though I trigger the operation from my tenant albin.latest.stage.c8y.io, the url filed in the request payload contains the value https://t37070943.latest.stage.c8y.io/inventory/binaries/4119377 with the actual tenant id t37070943 instead of the alias albin in it. When we send the 120 message, the URL must match what was received in the request. But, even when the proxy URL is converted using the new c8y_url_from_proxy_url function, the host is replaced with what was configured as c8y.url (albin.latest...) and not the one it received in the request. This is the cause of the warning.
To fix this without any disruptive changes (by changing the remoteUrl value itself), I'd suggest that we pass an additional cloud_url field in the config_update request payload with the same value from the c8y request. When the request completes, this same value can be used to send the 120 message. With such a change, we wouldn't need the c8y_url_from_proxy_url conversion anymore.
crates/extensions/c8y_mapper_ext/src/operations/handlers/config_update.rs
Outdated
Show resolved
Hide resolved
crates/extensions/c8y_mapper_ext/src/operations/handlers/device_profile.rs
Outdated
Show resolved
Hide resolved
…orrectly Signed-off-by: Krzysztof Piotrowski <krzysztof.piotrowski@inetum.com>
28f7360 to
aa5e9d1
Compare
aa5e9d1 to
9b73639
Compare
There was a problem hiding this comment.
LGTM.
Though the unit test coverage is good enough, it would be better to update the existing config_update and device_profile system tests to validate the newly added c8y_Firmware and c8y_Configuration_XYZ fragments as well, esp since most of the recent fixes were about minor mistakes in those fragment contents.
c75a678 to
617fb90
Compare
albinsuresh
left a comment
There was a problem hiding this comment.
LGTM. Thank you for the persistent efforts on this PR.
Signed-off-by: Krzysztof Piotrowski <krzysztof.piotrowski@inetum.com>
Signed-off-by: Krzysztof Piotrowski <krzysztof.piotrowski@inetum.com>
617fb90 to
580e897
Compare
Proposed changes
This PR adds operation fragments messages for
device profileand switch the order of those messages forfirmware/software updateso that they are sent before the succesful state change.Additionally, the structure of
device profilecommand was changed as it was not deserializing properly. Theremote_urlfield was changed toStringfromOption<String>as it is the mandatory field (this does not affect code as it was derived from mandatory value anyway).Types of changes
Paste Link to the issue
Checklist
cargo fmtas mentioned in CODING_GUIDELINEScargo clippyas mentioned in CODING_GUIDELINESFurther comments