Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Variant Aware Migrations #1105

Open
webern opened this issue Sep 3, 2020 · 0 comments
Open

Variant Aware Migrations #1105

webern opened this issue Sep 3, 2020 · 0 comments
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

Comments

@webern
Copy link
Contributor

webern commented Sep 3, 2020

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.

@gregdek gregdek added type/enhancement New feature or request status/notstarted labels Apr 2, 2021
@gregdek gregdek added this to the backlog milestone Apr 2, 2021
@stmcginnis stmcginnis added status/needs-triage Pending triage or re-evaluation and removed priority/p2 labels Dec 1, 2022
@stmcginnis stmcginnis added status/icebox Things we think would be nice but are not prioritized area/settings Issues related to our settings handling and removed status/needs-triage Pending triage or re-evaluation labels Feb 16, 2023
@stmcginnis stmcginnis removed this from the backlog milestone Feb 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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
Projects
Status: No status
Development

No branches or pull requests

3 participants