-
Notifications
You must be signed in to change notification settings - Fork 898
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
Remove Settings.product.transformation - v2v no longer conditional on product feature #17711
Conversation
… product feature Depends on ManageIQ/manageiq-v2v#490 (and ManageIQ/manageiq-v2v#417). Second part of the fix for ManageIQ/manageiq-v2v#432
Checked commit https://github.com/himdel/manageiq/commit/130ee97a012c658f7e84f87ac463059d41734fda with ruby 2.3.3, rubocop 0.52.1, haml-lint 0.20.0, and yamllint 1.10.0 |
@miq-bot add_label gaprindashvili/yes |
Restarted travis. |
Was this ever released? If so I think we would need a migration as well to remove this key from |
I am not quite sure. It was meant for Gaprindashvili z-stream. @AllenBW, @AparnaKarve, can you answer @carbonin 's question, please? |
When these PRs #17270 and #17285 were created, the idea was to disable v2v feature in 5.9.3 by default and enable it on upstream. (/cc @gmcculloug ) But if the above requirement has changed, and if we indeed want to get rid of the |
If we intend to keep the flag for Gaprindashvili only, then this PR and ManageIQ/manageiq-v2v#490 need to be |
@AparnaKarve The feature is moving from preview to general availability on the gaprindashvili branch which is why the flag is no longer needed. Does that help? |
@gmcculloug Thanks - that helps. In that case, the PR is GTG. |
I agree with @carbonin that this requires a data migration to delete any records. Technically it doesn't hurt anything having an "extra" key in there, but if a choice was made and we are no longer honoring that choice, then it's potentially confusing for a user. Better to just delete the setting. |
OK, created a data migration - ManageIQ/manageiq-schema#236 |
hmm, a data migration for Gaprindashvili - I suppose we can make one exception? For G, another option to consider would be to just flip the In discussion with @gmcculloug, he suggested this option - it's a great option if we don't want to deal with migrations in Gaprindashvili |
IMO we don't need the migration in gaprindashvili, as long as we don't mind the extra key there. But OTOH I don't see any harm in backporting that particular migration. I don't have an opinion here. |
@AparnaKarve @himdel There's no harm in backporting the migration, but even if we don't backport it, it's something that still needs to be done. |
@Fryguy can correct me if I'm wrong, but I think the normal z-stream updates do not run migrations, so the migration file would be there but no one would run it. |
@himdel The recommended approach would be create a PR on At this point it looks like we just have to change the label on this PR and ManageIQ/manageiq-v2v#490 to |
Aah, OK @gmcculloug , thanks :). On it.. #17733 @miq-bot add_label gaprindashvili/no |
Depends on ManageIQ/manageiq-v2v#490 (and ManageIQ/manageiq-v2v#417). (Both merged now.)
Second part of the fix for ManageIQ/manageiq-v2v#432
Cc @Fryguy