Managed Deployments

[joshk]

I had a call with two NervesHub users the other week where we talked about things they would like to see added/changed/removed, etc.

One of the topics we explored was deployments and how tag deployments don't entirely work for them.

Some of the problems mentioned include:

• devices should only belong to one deployment
• alternate deployments are confusing
• and looking at a deployment doesn't tell you how many devices belong to it and what version they are on.

This issue is to track some ideas I have around the topic.

Some ideas I would like to incorporate into a 'refresh' include:

• devices aren't placed into deployment groups via tags; instead, devices are placed in explicitly
• looking at a deployment group will show how many devices are in there, how many are on the latest version, how many are in the deployment group but have updates paused, and how many haven't been seen in x period

[joshk]

After talking to @fhunleth and @jjcarstens , we have general agreement to remove the Deployment matching based on conditions specified in the Deployment.

Instead, the deployment will be set on the Device and will not be changed unless it is explicitly changed.

This simplifies a lot of deployment logic, especially in DeviceChannel.

[joshk]

Ok, so here is my idea...

We leave the current Deployments code as is for now, and instead build this new ManagedDeployment/DeploymentGroup (name to-be-confirmed) independently with an opt-in process.

For simplicity sake, I'll refer to ManagedDeployment/DeploymentGroup as DeploymentGroup for now.

My general ideas around this refresh:

• A DeploymentGroup would be assigned to a Device explicitly.
• If a Device is registered via JITP then we can support rules based on Device tags which assign a DeploymentGroup to the Device
• A DeploymentGroup manages the firmware and archives for a group of Devices. It will include some general settings for deployment updates, but you won't update firmware or archives here, that will be done via a DeploymentUpdate (naming tbc)
• A DeploymentUpdate includes the firmware and archive being deployed, as well as when the deployment was created, who created it, and its status.
• This modelling gives us a history of deployments in the DeploymentGroup, including how many devices got this deployment.
• There can only be 1 active DeploymentUpdate per DeploymentGroup. When you create a new DeploymentUpdate then it will become the new 'active' deployment.
• DeploymentUpdates will include stats on how many devices the deployment got to, how many were in the DeploymentGroup at the time (which will allow for percentages)

I believe this is a good place to start, and can be improved upon in iterations.

One possible addition to this Roadmap (of sorts) is the ability to restrict firmware signed by a particular signing key. This can act as a safety net so Dev or QA builds don't go out to production devices.

[joshk]

Ok, further naming thoughts:

Context: ManagedDeployment - This is the complete grouping of schemas for the Managed Deployment feature.

Models:

DeploymentGroup
Devices belong to one Deployment Group at a time. The Deployment Group includes settings related to how a deployment is rolled out.

Deployment (or DeploymentUpdate?)
Encompasses a Firmware and an Archive (optional). Only one Deployment per Deployment Group can be active at once. A new Deployment will be promoted to active, while the previous active Deployment will no longer be active.

DeviceDeployment
This is to track the deployments a device has received, including its state (updating, delayed, failed, retry count)

[nshoes]

Josh and I planned this out a bit more yesterday. Note that none of this is final and all thoughts and recommendations are very welcome.

Schemas

Deployment -> DeploymentGroup

• rename everything but still use "deployments" schema for now, rename later
• active_deployment_release_id

DeploymentRelease

• deployment_group_id
• firmware
• archive
• status
  • active
  • error
  • stalled or paused
  • complete
• created_by: user_id (double-check convention)
• for later (UI dictates these more than not):
  • initial_device_count
  • updated_device_count

DeploymentReleaseDevice (name tbd)

• create once DeploymentRelease is created
• deployment_release_id
• device_id
• track state of the DeploymentRelease to show history of device's deployments

Contexts

ManagedDeployments

• will replace Deployments

Development Stages

Round 1

• remove deployment recalculation
• only recalculate when no deployment_id

Round 2

• DeploymentGroup + DeploymentRelease
• Orchestrator working the same, integrated w/DeploymentRelease

Round 3

• DeploymentReleaseDevice

Round 4

• Deployment release workflow
• pre-check: horde and how it works, one workflow GenServer per deployment across the cluster
• maximizing visibility of individual deployment steps
• more control for the user