Query / Control Mender Client for Multiple Artifacts

General Discussions
1

Hi Mender team,

We have been using Mender for OS A/B updates for some time, which is working well for us. We would like to expand this in two ways:

  • We would like to allow our users to see what updates are available and then confirm when they would like allow updates to start at their convenience.
  • We would like to extend the update system to additionally support application updates as Mender artifacts.

I believe the first point is adequately supported by the existing Mender client, through the use of state scripts, hooking the Download Exit state change.

The second point makes things more complex. The behaviour of the stock Mender client is to grab the next available update as soon as it is ready and begin the Download state, even if there is both an OS update and an application software update available.

Ideally, our software would present both options to the user, to allow them to see their respective changelogs. Once the user has kicked off the update, it would be up to our application software to decide in which order to install the OS and application updates. It doesn’t look like the stock Mender client would allow such a use case, but please let me know if there is an option I am missing! I have been playing with the “–depends” flag for artifact creation, but this is really more of a server-side field, the Mender client will still grab the first available update rather than let the application software see that both updates are available.

We are very much trying to avoid packaging both the OS and the application software into a single artifact. The application software sees far more frequent updates so we are trying to avoid packaging the whole OS with each.

As a workaround, I was hoping to instead interact directly with the Mender device API to get a list of available updates, and then start the Mender client manually to install them. I can grab a JWT token and interact with the REST endpoints, but I’m a bit stuck for how the specifics of the parameters can be used.

It appears the stock Mender client will poll the deployments/next endpoint for the next available update artifact.

The /artifacts endpoint looks more promising, suggesting that it can show the available artifacts for the device. However it appears to only be able to return data when the exact name of the artifact is supplied. Since artifacts must have unique names, it appears to only allow a single returned record, when the artifact name is already known? I have tried to replace the artifact name sent as part of that query with wildcards and empty strings, but these do not work.

Could you advise if there is anything that I can try to:

  • Allow the Mender client (or our software) to discover what updates are available before they are deployed
  • Allow the Mender client (or our software) to trigger update artifacts in a selected order.

Thank you for your help.

2

I don’t think this is possible with our current implementation. And Mender was not designed with this workflow in mind. Still let me join you in the brainstorming process :slight_smile:

What I may suggest is to treat the device as a management device as well. Let me explain:

We offer two groups of endpoints:

  • The one intended for being used within the device
  • The one is supposed to be used from a workstation
    • In fact, our Mender UI make usage of this one

With the management endpoints you can list artifacts and filter them just like you do with the Web interface.

Notice you can add tags to the different releases (a release is a server concept that could have one or more artifacts, each for a different device type) and then you can use these tags for filtering purposes if it makes sense.

Then you can list the available artifacts to a specific device, and then when a client selects it by using the device’s UI, then you can create a deployment for only this device with this specific artifact.

Then the mender client will just pick it up. Does it make sense?

Same as before, if you trigger them by using the management endpoint, then the server will respect the same order and the device will consume them from the oldest to the newest deployment. I think this diagram may help to understand how Mender client will pick the artifacts:

image
image1526×1077 93.4 KB

From Deployment | Mender documentation

Hope it helps,
Luis

3

Hi Luis,

Thanks for getting back to me.

Yep that makes total sense, and a clever solution. I will have a bash at getting that working next week and let you know how I get on.

Cheers,
Brendan