Mender-convert and mender-configure artifact interference

General Discussions
, , ,
1

Hey guys,

Its me again. I have encountered an expected behaviour which I am unsure how to tailor to my scenario. Let me elaborate.

I am using mender-convert with an mender_create_artifact hook. This results in 2 important files in my case:

  • a flashable *.img file to commission new devices (this is the approach I have taken)
  • *.mender artifact, which is to be deployed to the current fleet to bring devices in the field up to date

After flashing *.img file I am receiving from mender convert, I am using mender-configure to setup hostname and timezone. After all that, I am deploying *.mender artifact, generated via mender-convert to the entire fleet.

The fleet receive the artifact update and follows the usual routine. However, the newly commissioned device does receive the artifact too.

Below is step-by-step scenario I am following:

  1. Use mender-convert to generate *.img and *.mender artifact
  2. Flash *.img to a device
  3. Accept newly commisioned device on a dashboard
  4. Deploy mender-configure artifact to finalise setting the device up
  5. Deploy *.mender artifact generated via mender-convert

In this case, a newly comissioned device accepts the update and proceeds to download and install it.

Additionally, I have tested another scenario without using mender-configure. In this case I am getting a desired behaviour:

  1. Use mender-convert to generate *.img and *.mender artifact
  2. Flash *.img to a device
  3. Accept newly commissioned device on a dashboard
  4. Deploy *.mender artifact generated via mender-convert

In this case, a newly commissioned device rejects the update as it is already installed.

Since mender-configure follows a usual artifact flow, it seem to overwrite the latest installed artifact meta data. This makes the client think that mender-convert artifact is not installed, so it proceeds downloading and installing it. However, in my case, I want client to reject this update as it is already installed.

How can I ensure that A/B artifact is not applied after using mender-configure? Can I achieve so via usage of depends/provides? Or do I need to change my deployment strategy?

Looking forward for your responses.

2

After RTFM and testing out deployments, I have figured out the exact deployment strategy I have to follow:

  1. Use mender-convert to generate *.img and *.mender artifact
  2. Flash *.img to a device
  3. Deploy *.mender artifact generated via mender-convert
  4. Accept newly commisioned device on a dashboard
  5. Deploy mender-configure artifact to finalise setting newly comissioned device up

I realised, I am using static groups. Hence, start of a deployment will deploy only to the devices already existing within the targeted deployment group. Hence, I have to deploy artifact before I accept device authorisation on a dashboard (aka comission device via the dashboard). *.mender artifact deployment will start without having new device targeted for the deployment because device is simply not comissioned yet. And when device is comissioned - deployment group is not having newly comissioned device in it, so update will not be applied to newly comissioned device.

1 Like