Deployments as devices move between dynamic groups

General Discussions
1

We use a GitOps pipeline to provision Mender Device configuration (side note: would be awesome if Mender provided a Pulumi Package!). This includes a tag deploymentGroup that is used to include the device in a dynamic group which are the target of deployments. To make it concrete, two commonly used deploymentGroups are:

  • ExternalBeta
  • InternalInventory

It’s common that InternalInventory gets a newer version of SoftwareX than ExternalBeta (e.g. to have access to new manufacturing QA functionality).

When the device is ready to ship to a customer, our GitOps pipeline will set the deploymentGroup to ExternalBeta (among other configuration/tags). If a device is RMA’d, it will get put back in InternalInventory and we would expect that version of SoftwareX gets deployed appropriately.

What’s the right way to handle this in Mender? Our original approach/thinking was that simply having indefinitely running deployments targetting dynamic groups would allow us to move devices freely from one dynamic group to another and have deployments that would do the Right Thing. But after seeing the actual behavior and then re-reading the docs on dynamic groups (“principle of guaranteeing a predictable”, “won’t take part in the same Deployment twice”), it doesn’t seem to be so simple.

We are on a hosted Enterprise plan.

2

Hi @tbraunjones,

From my understanding a combined approach of a long running deployment to a dynamic group, and a directed deployment - not sure if that is a commonly used term - to an eventually RMA’ed device.

  1. a long running deployment to a dynamic group InternalInventory, which deploys the current software. This deployment is stopped and recreated with a new artifact upon each release.
  2. upon RMA, I presume there is some process (which also triggers the new tagging), and during that you can create a deployment which just targets the processed device with the desired latest software. The API (Mender API docs) offers a convenient way for that, by this configuration:
	name: device_id,	# Note: adding a real name here breaks the GUI, see MEN-6931
	artifact_name: artifact_name,
	devices: [
		device_id
	],
	all_devices: false

The reasoning is that step 2 covers the time between the RMA process, and until the next software release (which is step 1).

Hope that helps,
Josef

3

Thanks for the quick response. I’ll look into this. It sounds like burden is on us more than I hoped it would be. I was expecting to find what I see with other modern DevOps tooling where the approach is to configure a desired state and the tool reconciles differences with the actual state and does what’s necessary to get it into that desired state.