Skip to content
This repository has been archived by the owner on May 21, 2024. It is now read-only.

Use latest endpoint for /system_info #1421

Merged
merged 2 commits into from
Oct 22, 2019
Merged

Use latest endpoint for /system_info #1421

merged 2 commits into from
Oct 22, 2019

Conversation

simao
Copy link

@simao simao commented Oct 17, 2019

Fixes https://saeljira.it.here.com/browse/OTA-3379

Only works in production, not sit, due to https://saeljira.it.here.com/browse/OTA-3936

Will change device-gateway so that legacy devices can still use /core/system_info

@simao simao requested review from lbonn and pattivacek October 17, 2019 17:20
@doanac
Copy link
Collaborator

doanac commented Oct 17, 2019

I like the idea and requested a similar change a long time ago. However, this is going to break my deployment. I think this commit message should probably include what changes will be needed to the device-gateway and maybe some context about the bug you've referenced.

@simao
Copy link
Author

simao commented Oct 17, 2019

rvi core is deprecated and not in use any more, so going forward all references to it should be removed. device-registry handles this api now, and the last versions of core forward the data to device-registry.

Device gw should proxy /core/system_info to api/v1/devices/:uuid/system_info, which is handled by device registry.

The bugs I referenced report that aktualizr does not upload system info properly.

@@ -186,7 +186,7 @@ data::InstallationResult SotaUptaneClient::PackageInstallSetResult(const Uptane:
void SotaUptaneClient::reportHwInfo() {
Json::Value hw_info = Utils::getHardwareInfo();
if (!hw_info.empty()) {
http->put(config.tls.server + "/core/system_info", hw_info);
http->put(config.tls.server + "/system_info", hw_info);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@patrickvacek Perhaps it makes sense to introduce another configuration variable to set a device registry URL explicitly as in case of Director, ImageRepo and Treehub, config.tls.server is kind of opaque/vague - not clear to which of the backend services it points to.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

config.tls.server is the URL for the device gateway. We can rename it, but then we have to maintain backwards compatibility with the old name, which sounds tedious.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure if backwards compatibility is required for real customers as this variable is basically automatically defined by aktualiz.
Also, there is inconsistency in the way how URLs are defined in the config, there are service specific URLs for all backend services except DeviceRegistry.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure if backwards compatibility is required for real customers as this variable is basically automatically defined by aktualiz.

We can't really guarantee that. If someone has overwritten tls.server in their config and then we change the name of the config variable in an update, their device will break and require manual intervention.

there is inconsistency in the way how URLs are defined in the config, there are service specific URLs for all backend services except DeviceRegistry.

That's more or less abstracted from us. It depends on how the endpoints are defined in the device gateway, since that's the only service (other than treehub) that we actually talk to directly. We can't really do anything about that unless there is a specific path only used for forwarding to device registry, which I'm not sure is true. @simao or another backend dev may know better.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If someone has overwritten tls.server in their config and then we change the name of the config variable in an update, their device will break and require manual intervention.

I understand it and that's what I thought initially too, but on second thought I don't see an use case of tls.server server custom overriding by a customer that will work on practice unless they override it by the same value as it's set by default - DeviceGateway URL. Anyway, this is really not important at the moment.

@pattivacek
Copy link
Collaborator

However, this is going to break my deployment.

@doanac Does this feature work in your deployment currently? It's been broken in ours for a while now. I'm not sure there's a good way to remain backwards-compatible on the aktualizr side; I don't want to have to have config variables for every last endpoint, and that might not even solve the problem. If you need to support the old version, the right solution is probably to support both endpoints on the backend.

simao and others added 2 commits October 18, 2019 09:23
rvi core is deprecated and not in use any more, so going forward all
references to it should be removed. device-registry handles this api
now, and the last versions of core forward the data to device-registry.

Device gw should proxy /core/system_info to
api/v1/devices/:uuid/system_info, which is handled by device registry.

Signed-off-by: Simão Mata <[email protected]>
@pattivacek
Copy link
Collaborator

@simao I put some of the text you posted in the commit message as requested by Andy. I also pushed a fix for the test that was breaking. While doing so, I noticed that we're sending the list of installed packages to /core/installed. Should that also get changed?

@doanac
Copy link
Collaborator

doanac commented Oct 18, 2019

Does this feature work in your deployment currently?

@patrickvacek - We created an out-of-tree patch to get it working:
https://github.com/advancedtelematic/ota-community-edition/pull/69/files
foundriesio/ota-community-edition@499bfcd

In the case of this change, I'll just add another nginx proxy section to handle things.

@pattivacek
Copy link
Collaborator

@mike-sul FYI test_backend_failure keeps breaking on Travis. It won't stop us from merging this if everyone is happy with it, but it would be good to understand what's going wrong with that test.

@doanac I'm interested in seeing this made more consistent going forward as well, and I think this is a step in the right direction, assuming system_info is the endpoint for device registry. I'll defer to @simao and the rest of the backend team, though.

@mike-sul
Copy link
Collaborator

@mike-sul FYI test_backend_failure keeps breaking on Travis. It won't stop us from merging this if everyone is happy with it, but it would be good to understand what's going wrong with that test.

Yeah, I see it, will try to figure it out, seems like some kind of race condition.

Copy link
Collaborator

@pattivacek pattivacek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Merging as this seems like the right thing to do and I haven't heard a solid reason to hold back.

@pattivacek pattivacek merged commit ca422f8 into master Oct 22, 2019
@pattivacek pattivacek deleted the use-system-info branch October 22, 2019 07:42
@simao
Copy link
Author

simao commented Oct 22, 2019

@patrickvacek yes, /core/installed should be changed but not yet because there is no support for a new endpoint in device-gateway, /system_info is already supported in device gateway.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants