Bug 1866723

> af-south-1 shoudl be an `unknown` region, and


af-south-1 is not a region that requires user to provide the endpoints, because we already have the endpoints for that region in the embedded SDK.
So any user should be able to use that region using the install-config.yaml without also providing the endpoints.
Users cannot pick that region from TUI because we do not have an AMI for the region.

I do not think there is a bug here.

The region is new in April [1].  Should this be a ticket to RHCOS about getting the AMI copied into the new region?  Prior art for eu-north-1 in bug 1765269.

[1]: https://aws.amazon.com/blogs/aws/now-open-aws-africa-cape-town-region/

Hello Abhinav,

1. According to definition in the document https://github.com/openshift/enhancements/blob/master/enhancements/installer/aws-custom-region-and-endpoints.md#custom-regions 

>> The installer although should keep track if the specified region is known. A region is known when
>>    There is RHEL CoreOS AMI for the region known to the installer binary.
>>    The regions is one of the known regions to the AWS SDK vendored into the binary.`


So in my test cases, these three regions are custom/unknown region (af-south-1, ap-east-1, eu-south-1)

But from your description, af-south-1 is not an unknown region since it has been supported by SDK.

Need your confirm, af-south-1 will be a known region (after AMI uploaded), how about ap-east-1, eu-south-1? Will be the same as af-south-1 region as a known region?

2. the same issue was also occurred in region us-gov-west-1: openshift-installer does not report validation error and starts to create resources. 

INFO Consuming Install Config from target directory
INFO Credentials loaded from the "default" profile in file "/home/ec2-user/.aws/credentials"
INFO Creating infrastructure resources...

$ git --no-pager log --oneline -1
514166ea6 (HEAD -> master, origin/release-4.7, origin/release-4.6, origin/master, origin/HEAD) Merge pull request #4026 from wking/try-openshift-com-moved
$ git --no-pager grep 'af-south-1\|ap-east-1\|eu-south-1'
pkg/types/aws/defaults/platform.go:             // "ap-east-1":      {"m5", "m4"},
vendor/github.com/aws/aws-sdk-go/aws/endpoints/defaults.go:     AfSouth1RegionID     = "af-south-1"     // Africa (Cape Town).
vendor/github.com/aws/aws-sdk-go/aws/endpoints/defaults.go:     ApEast1RegionID      = "ap-east-1"      // Asia Pacific (Hong Kong).
vendor/github.com/aws/aws-sdk-go/aws/endpoints/defaults.go:     EuSouth1RegionID     = "eu-south-1"     // Europe (Milan).
...
vendor/github.com/terraform-providers/terraform-provider-aws/aws/hosted_zones.go:       "af-south-1":     "Z11KHD8FBVPUYU",
vendor/github.com/terraform-providers/terraform-provider-aws/aws/hosted_zones.go:       "ap-east-1":      "ZNB98KWMFR0R6",
vendor/github.com/terraform-providers/terraform-provider-aws/aws/hosted_zones.go:       "eu-south-1":     "Z3IXVV8C73GIO3",

So looks pretty good to me once we get AMIs for the new regions.  You should be able to test by performing the cross-region AMI copy yourself and setting an explicit AMI via amiID [1].

[1]: https://github.com/openshift/installer/blob/master/docs/user/aws/customization.md#cluster-scoped-properties

> (af-south-1, ap-east-1, eu-south-1)

All three of the regions do not need any service endpoints to be set because they are already known by the SDK in use by installer.

As a general rule, the service endpoints are designed for 2 use cases:

- really private regions like C2S ans SC2S
- when users want to use alternate endpoints for region, like see here https://aws.amazon.com/compliance/fips/ for fips endpoints for GovCloud.
- when users are trying to use PrivateLink for suported services https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html


> Need your confirm, af-south-1 will be a known region (after AMI uploaded), how about ap-east-1, eu-south-1? Will be the same as af-south-1 region as a known region?

All reginos that have AMI published and updated in installer will show up in the Terminal Prompts. So I would say yes.

Abhinav，

thanks for your confirm.

As my note in https://bugzilla.redhat.com/show_bug.cgi?id=1866723#c3

> 2. the same issue was also occurred in region us-gov-west-1: openshift-installer does not report validation error and starts to create resources. 
> 
> INFO Consuming Install Config from target directory
> INFO Credentials loaded from the "default" profile in file "/home/ec2-user/.aws/credentials"
> INFO Creating infrastructure resources...

I think it is a problem, and installer should provide validation capability.

(In reply to Yunfei Jiang from comment #6)
> Abhinav，
> 
> thanks for your confirm.
> 
> As my note in https://bugzilla.redhat.com/show_bug.cgi?id=1866723#c3
> 
> > 2. the same issue was also occurred in region us-gov-west-1: openshift-installer does not report validation error and starts to create resources. 
> > 
> > INFO Consuming Install Config from target directory
> > INFO Credentials loaded from the "default" profile in file "/home/ec2-user/.aws/credentials"
> > INFO Creating infrastructure resources...
> 
> I think it is a problem, and installer should provide validation capability.

^^ Can you explain a little more which exact case you would have seen the installer provide validation and what kind of validation.

Just to repeat from https://bugzilla.redhat.com/show_bug.cgi?id=1866723#c5

All regions including af-south-1, ap-east-1, eu-south-1, or us-gov-west-1, us-gov-east-1 would NOT need any service endpoints as the installer already has endpoints for these regions.

> af-south-1, ap-east-1, eu-south-1, or us-gov-west-1, us-gov-east-1

For all the regions mentioned above the installer does not need service endpoints and therefore validations are not required for these region.