[DARGA] removed gov cloud from aws list of regions

[durandom]

addresses https://bugzilla.redhat.com/show_bug.cgi?id=1349423

@miq-bot assign chessbyte

[Fryguy]

@chessbyte Can you hold on merging to darga? I have reservations about the original PR ManageIQ/manageiq-providers-amazon#38

[durandom]

@Fryguy how do you like this? gov_cloud would be disabled by default and customers that need it, can enable it through a setting.

I'd put up a PR for master in the amazon repo, once this is merged

[durandom]

cc @blomquisg

[durandom]

@Fryguy could you give your 👍 or 👎 ?

[Fryguy]

@durandom So I was thinking something much more generic, because you are going to need this in other providers. For example, in Azure there are actually multiple gov cloud regions, and what's to say that amazon won't also create multiple at some point. Ultimately the feature is to "disable regions"...we just so happen to need gov cloud, but why not be able to disable any region? So I was thinking having a setting in each provider settings section called "disabled_regions"

:ems_amazon:
  :disabled_regions: []

By default it's empty, but one could do:

:ems_amazon:
  :disabled_regions:
  - us-gov-west-1

What's nice about this approach is it opens up multiple things

• Cross-provider support for disabling regions
• User-specific disablement of regions...say a customer doesn't want their users to accidentally use a non-US-based region.
• Non-gov region disablement (for example China on Azure works differently that other regions and may not be available, so a company may want to disable it).

[Fryguy]

Also, on ManageIQ I don't believe we should disable anything by default, whether it's providers, regions, translations, or whatever. @blomquisg Thoughts?

[durandom]

@Fryguy incorporated your suggestions. The downside is, the regions are filtered at runtime. But thats not a real performance issue, since its just small array/hash operations.

[Fryguy]

@durandom This is perfect 👍

So, as far as backporting goes, let's get into master on the gem, and then backport

[miq-bot]

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

[durandom]

So, as far as backporting goes, let's get into master on the gem, and then backport

Yea, but the gems dont support settings.yml yet, so backporting via cherry-picking would result in a conflict anyways :/

So, lets get #10944 in and then continue on this ManageIQ/manageiq-providers-amazon#44

For now, I'd let @chessbyte merge this PR as is

[Fryguy]

I'll leave it up to @chessbyte, then. Downstream first always concerns me.

[durandom]

Downstream first always concerns me.

Totally agree, and would be there only 1 day to go, I'd wait until we can have the same implemented in master.

So, @chessbyte, merge ?