Remove Settings.product.transformation - v2v no longer conditional on product feature

[himdel]

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

[miq-bot]

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
0 files checked, 0 offenses detected
Everything looks fine. 👍

[himdel]

@miq-bot add_label gaprindashvili/yes

[martinpovolny]

Restarted travis.

[carbonin]

Was this ever released? If so I think we would need a migration as well to remove this key from settings_changes right? /cc @Fryguy

[martinpovolny]

I am not quite sure. It was meant for Gaprindashvili z-stream. @AllenBW, @AparnaKarve, can you answer @carbonin 's question, please?

[AparnaKarve]

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 )
So, a little surprised to see this PR...

But if the above requirement has changed, and if we indeed want to get rid of the Settings.product.transformation flag, then the PR looks good.

[AparnaKarve]

If we intend to keep the flag for Gaprindashvili only, then this PR and ManageIQ/manageiq-v2v#490 need to be gaprindashvili/no

[gmcculloug]

@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?

[AparnaKarve]

@gmcculloug Thanks - that helps.

In that case, the PR is GTG.

[Fryguy]

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.

[himdel]

OK, created a data migration - ManageIQ/manageiq-schema#236

[AparnaKarve]

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 transformation flag to true
Advantage - no data migrations required in G

In discussion with @gmcculloug, he suggested this option - it's a great option if we don't want to deal with migrations in Gaprindashvili

[himdel]

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.

[carbonin]

@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.

[gmcculloug]

@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.

[gmcculloug]

@himdel The recommended approach would be create a PR on Gaprindashvili which changes the flag from false to true. Upstream we remove the setting, include the migration and remove the UI check for the flag.

At this point it looks like we just have to change the label on this PR and ManageIQ/manageiq-v2v#490 to gaprindashvili/no and create the Gaprindashvili PR to change the existing flag to true.

[himdel]

Aah, OK @gmcculloug , thanks :). On it.. #17733

@miq-bot add_label gaprindashvili/no
@miq-bot remove_label gaprindashvili/yes