Fundamentally, allows going from one model assertion to another
In some cases this might be a new revision of the assertion, which means it’s automatically updated
In other cases, it would be a manual (or driven externally to snapd) action shifting from one model assertion to a different one
We need to research how to integrate the remodeling procedure into the serial vault, so that the device can become a new model as soon as it requests a serial for itself.
The goal is allowing changing of all details of the model: base filesystem snap, kernel, gadget, store, required snaps, etc.
Internally in snapd, we hope to implement all those changes using the same code path. Among other things, that means being able to shift back to a previous model.
Change of model needs to be approved in the model itself, with language to be defined.
Change should be approved in both directions. That is, the target model should be able to restrict which models it can be transitioned from.
Wildcards allows accepting all transitions (or perhaps not specifying anything allows all transitions, TBD).
Restrictions might be specified per brand, maybe?
There might be use cases to allow the gadget to start the remodeling via snapctl.
Ideally serial would be obtained in the beginning of the transition so it can use it to communicate, but there’s a chicken and egg problem, because downloading the new gadget might require a conversation with the right brand store, and the new gadget might be required to acquire the new serial, and the new serial is required to talk to the right brand store. Loop must be broken somewhere.
We might start with a smaller use case where only some fields in the model are allowed to transition. Changing only the store, and perhaps installing non-core required snaps (not kernel, gadget, core, base) might be easier.
There are legacy cases which use a store but are using the generic model. This is an unsupported use case, and needs to be ported to a normal scenario where a model is involved and detailing the store.