Right now, any image can be upgraded to any other image and the add system image script will not warn the user if they are trying to upgrade to a flavor that will not actually work with their platform.

In some cases upgrading to a mismatched flavor is harmless, but other times it's outright dangerous: e.g. upgrading an Azure instance to a flavor without waagent in it will result in some Azure service like automatic instance backup no longer working, without an immediate indication that something is not working anymore.

Upgrading a custom platform image to a generic ISO may lead to even worse consequences, like NIC numbering getting thrown off.

Since we are redesigning the build flavor system in T3664, it may be a good idea to also make flavor types first-class entities.

The Proposal

Add three new fields to /usr/share/vyos/version.json : build_flavor, build_flavor_description, and build_flavor_strict_match.

The build flavor will come from the flavor file, e.g. "generic-iso", "azure" etc.

By default, the add system image script should warn the user about flavor mismatch and ask a yes/no question.

If build_flavor_strict_match is true, then the script should not allow upgrading at all.

The build_flavor_description field may be used in the script to tell the user what platforms the image is good for.

Mockup:

$ add system image https://example.com/vyos-1.3.0-xcpng-amd64.iso
...
Your running image flavor is "generic-iso".
The new image flavor is "xcp-ng".
Upgrading to a different image flavor may cause functionality degradation or break your system.
Do you want to proceed? [y/N]

$ add system image https://example.com/vyos-1.3.0-dell-amd64.iso
...
Your running image flavor is "generic-iso".
The new image flavor is "dell" (for Dell VEP1400 and VEP4600 platforms).
Image flavor "dell" is incompatible with other flavors, not installing the image.