[WIP] Settings for providers

[durandom]

Purpose or Intent

support for having the same settings.yml files in the config and environments directory for provider gems

@miq-bot add_label pluggable providers, wip
@miq-bot assign Fryguy

cc @blomquisg

[durandom]

this and the other _() thing is unrelated, but is need for this.
Because settings.rb now triggers loading all subclasses and _() does not work without settings

[durandom]

corresponding PR in the amazon repo ManageIQ/manageiq-providers-amazon#41

[durandom]

@Fryguy are you ok with the general direction of this?

[durandom]

commit 702a293 is also in #10964

[Fryguy]

@durandom Still thinking about this one...it feels kind of invasive at the various layers. One thing I like about @bdunne's approach is that it encapsulates all of that into a Vmdb::Plugins object. Then, I can see asking that class for provider_engines or something.

[bdunne]

Also, this requires all plugins to subclass a provider. I have a couple use cases where I only want to provide an automate domain and a few non-provider models.

[durandom]

I'll wait until #11083 got merged and make use of Vmdb::Plugins then

[miq-bot]

<pr_mergeability_checker />This pull request is not mergeable. Please rebase and repush.

[durandom]

@miq-bot remove_label wip

@bdunne @Fryguy now it's much cleaner, thanks 🌹

regarding the order: I'm not sure if the plugins should be able to override core settings from manageiq (this is how its now) or the other way round.

[miq-bot]

Checked commit durandom@e13fedb with ruby 2.2.5, rubocop 0.37.2, and haml-lint 0.16.1
1 file checked, 0 offenses detected
Everything looks good. 👍

[durandom]

regarding the order: I'm not sure if the plugins should be able to override core settings from manageiq (this is how its now) or the other way round.

@Fryguy can you merge, if you are ok with this now?

[durandom]

@Fryguy ping

[Fryguy]

Looks really nice!

[cben]

Q: if we now add settings in say manageiq-providers-kubernetes/config/settings.yml and need the new settings backported, it will backport cleanly to fine but will need manual [EUWE] PRs, right?

Any chance this could be euwe/yes? I see #11083 was euwe/no.

Q: let's say you do add this support to euwe, would it help changes that become a hotfix onto say 5.7.1? I suppose no because this support would only go into later 5.7.z. Never mind then :)

[bdunne]

I don't see #11083 going back to euwe. It's too much risk at this point.

[durandom]

Q: if we now add settings in say manageiq-providers-kubernetes/config/settings.yml and need the new settings backported, it will backport cleanly to fine but will need manual [EUWE] PRs, right?

It could be, because the path is the same, but probably will not, because git/diff will not have enough context to apply the patch. So it probably be a manual PR.