I have two questions concerning the compatibility between mender-client 4.x and artifact version 2:
-
Assuming an upgrade from Yocto Dunfell (mender-client 2.x) to Scarthgap (mender-client 4.x) with a v2 artifact. The v2 artifact is programmed using mender-client 2.x. Subsequently, can the v2 artifact be committed with mender-client 4.x?
-
Is there any way a v2 artifact can be used with mender-client 4.x at all? If no, why was this legacy support removed?
Hi @sabelsen,
Mender Client 4.0 only supports Artifact Format 3.0. The legacy format has been removed as the Client 3.x family has been the officially supported one for many years now, and we took the rewrite opportunity to slim down the codebase.
Given your situation, what is your actual concern? You want to upgrade from dunfell
to scarthgap
, I presume. As the artifacts are actually created by mender-artifact
, you also can generate a V2 artifact in a scarthgap
build by setting MENDER_ARTIFACT_EXTRA_ARGS
(see Variables | Mender documentation) accordingly. This can then be deployed to a fleet currently running legacy V2.0 clients.
Greets,
Josef
Thanks for your reply!
In general, my concern is about compatibility.
Broadly speaking, our fleet is running sumo, dunfell and kirkstone. We can upgrade or downgrade between them with the support of V2 artifacts. Unfortunately for us, we do also support software downgrading, and that is a use-case we have to consider. Scarthgap now introduces a break in compatibility without the support for the legacy format. I would assume we can upgrade to scarthgap with a V2 artifact (and commit it through ‘mender-update commit’). Downgrading from scarthgap means creating V3 artifacts for dunfell and kirkstone, but this will not work for sumo as its mender-client does not support V3.
The above introduces some new constraints and distribution of upgrade/downgrade instructions to our customers. It is doable but not optimal.
Hi @sabelsen,
Well, alternatively you can forward port Mender Client 2.x to scarthgap, or extend Client 4.x with support for Artifact Format V2. Or, as you said, create more specific artifacts.
Software maintenance often involves various tradeoffs and the “explicitly support downgrades” path is one we decided to not prioritise, as it is rarely needed and in most circumstances a bad idea to roll out unmaintained software with known vulnerability (such as sumo
).
Sorry I don’t have news more suited to your requirements.
Greetz,
Josef