Using API to get artifact name

General Discussions
1

I am trying to use the API (specifically api/devices/v2/deployments/device/deployments/next) to determine the name of any scheduled deployment. I’m doing this in a Download_Enter state script so that my device users can decide whether to allow the download/install or not. This is for a medical device and the end-users want complete control over when things are installed. We plan to include strings in the artifact name so that we can communicate details about the update to the end-users and let them make the decision. The workflow with these devices is such that they may wait weeks or potentially even months to install an update; and the devices are shutdown at the end of the day. We want to use Download_Enter so that the devices will not bother to download the data until the user requests it, and we don’t want the deployment to be marked as failed should the device be rebooted before the user allows the install.

I have some code that almost works but I regularly get failed deployments with the error Failure: Device provided conflicting request data. My state script and library sh script file are attached.

Does anyone have any idea what I am doing wrong and how I can accomplish this? cc: @merlin

Drew

2

Attachments here. I had to rename them with a yml extension to get them to post.

Drew
Download_Enter_00_Process_Update_Metadata.sh.yml (2.0 KB)
Mender_Server_API_header.sh.yml (3.3 KB)

3

You need to submit all the values that mender show-provides lists as well, in device_provides.

Btw, did you know that you can get the JWT directly from the client? Call this command:

dbus-send --print-reply --system \
  --dest=io.mender.AuthenticationManager \
  /io/mender/AuthenticationManager \
  io.mender.Authentication1.GetJwtToken

The two resulting strings will be the JWT token and server to connect to, respectively.

4

Nice. I have not yet investigated the DBUS API but that is definitely simpler than the mechanism I am using. I’ll experiment with your recommended changes.

Drew

5

@kacf the changes you suggested seem to work. Thanks.

But I have a related question; I’m using Yocto but when I boot the very first time, the output from mender show-provides is empty and only seems to get populated by a full artifact install. Is that expected? I recall there were things related to that for binary delta and checksums but I didn’t expect it for standard provides.

Is there any way to get this to work with a Yocto build.

Drew

6

Checksums are in fact Provides values, so it’s the same issue as the deltas, yes. The fix for this is non-trivial, but we are in fact working on this right now: [MEN-2582] Automatic bootstrap artifact - Northern.tech AS. We hope to get this into the next release.

7

The only workaround I know about is to install some dummy file in /tmp using the single-file Update Module, and then handcraft the Provides values to exactly what you need, to initialize the database.

8

So how does the client connect and query the next deployment if the database has not been populated? Does it use the V1 API? If so, what is the benefit of the V2 API for the use case of simply getting the artifact name of the outstanding deployment?

Drew

9

While the database is not initialized, there is no benefit, although it still does use v2, with a nearly empty Provides set. This is the only case where the client falls back on the /etc/mender/artifact_info file.

But this assumption is only valid before the first update, so it’s not wise to rely on it. It also won’t be true anymore after we fix the database initialization problem. The /etc/mender/artifact_info file will be removed as part of the upcoming fix, since it won’t be used anymore then.