Variant Aware Migrations #1105
Labels
area/settings
Issues related to our settings handling
status/icebox
Things we think would be nice but are not prioritized
type/enhancement
New feature or request
What I'd like:
#1100 adds a setting that is only relevant to the ECS variant. Looking at the code we realize this should be OK since a migration that adds a setting is actually a no-op, and removing a setting is also a no-op if the setting does not exist.
However, this raises an issue. The migration will be downloaded and executed for all variants despite being only relevant to the ECS variant.
It seems like a feature could be added to the build system and/or update system to only obtain/run migrations that are intended for the current variant (and arch?).
Any alternatives you've considered:
The first thing that comes to mind is increasing the richness of the data in Release.toml and pubsys such that migrations somehow specified per-variant and only added to the manifest when relevant. Also unsure at the moment if the manifest data format could still support multiple variants (as it currently can despite the fact that we are deploying one variant per manifest currently).
Another, much less appealing possibility would be to make the update system (updog/migrator) aware of the variant-ness of migrations and skip them when not applicable.
The text was updated successfully, but these errors were encountered: