Skip to content
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

Decouple tedge-mapper-c8y and tedge-agent for config_update #2477

Closed
rina23q opened this issue Nov 22, 2023 · 3 comments
Closed

Decouple tedge-mapper-c8y and tedge-agent for config_update #2477

rina23q opened this issue Nov 22, 2023 · 3 comments
Assignees
Labels
improvement User value
Milestone

Comments

@rina23q
Copy link
Member

rina23q commented Nov 22, 2023

Is your feature improvement request related to a problem? Please describe.
The config_update feature requires downloading files from cloud, then storing it to <data_dir>/cache directory (e.g. /var/tedge/cache). The cache feature is very helpful to save bandwidth because it can prevent downloading the same files multiple times from the internet.

As of now, upon receiving a config_update operation from c8y, tedge-mapper-c8y

  • checks if a file associated with remoteUrl is available in the cache directory
  • downloads a file if not available in the cache directory and stores the file to there

The problem is, accessing to <data_dir>/cache is the responsibility of tedge-agent. So, tedge-mapper-c8y should not access the directory directly. (For the background of decoupling, refer to #2390)

Describe the solution you'd like
The solution is not yet very clear. The must is that tedge-agent downloads a file from cloud.

Describe alternatives you've considered

Additional context

@rina23q rina23q added the improvement User value label Nov 22, 2023
@didier-wenzek
Copy link
Contributor

See #2071 (comment)

A solution could be to add a cache method in the file-transfer service. A POST request asking the tedge-agent to download a file from the cloud and to serve it locally.

@Bravo555
Copy link
Contributor

QA instructions

The modified test at tests/RobotFramework/tests/cumulocity/configuration/configuration_with_file_transfer_https.robot should cover the changes. The gist is that tedge-agent should now be fully functional when run on a separate device/container. The new device/container still has to be configured as the main device (via mqtt.device_topic_id) and http.client.host/port settings should be set only on that physical device on which the agent is running, so that a correct tedgeUrl is generated in operation message payloads.

@gligorisaev
Copy link
Contributor

QA has thoroughly checked the feature and here are the results:

  • Test for ticket exists in the test suite.
  • tests/RobotFramework/tests/cumulocity/configuration/configuration_with_file_transfer_https.robot
  • QA has tested the function and it's functioning according description.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
improvement User value
Projects
None yet
Development

No branches or pull requests

5 participants