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.