Similar to #50, the upstream addition of region cn-north-1 within boto 2.22.0 now triggers runtime failures due to this region requiring a dedicated account.
While this issue is about cn-*right now, it confirms my hunch back then that any dedicated handling will not scale, and a region neutral handling is also confirmed as the current upstream position in https://github.com/boto/boto/issues/1951#issuecomment-31493498.
Given the project at hand, I obviously disagree with the notion of cross region looping being that uncommon still, and would expect it to be used more frequently over time due to region failover and load balancing scenarios; in particular, all sorts of AWS account house keeping and backup scenarios are best done cross region from the get go I think.
So in hindsight the include/only solution derived from the AWS Tools for Windows PowerShell turns out to be short sighted, and also inconsistent with the existing --region parameter in the first place:
-r REGION, --region REGION
A region substring selector (e.g. 'us-west')
A better solution might be to expand this current substring handling to regular expressions, which would yield utmost flexibility, yet remain simple enough and explicit if so desired (e.g. (us-east-1|us-west-1)) - the default here could then just be the universally accessible ones (i.e. exclude gov and cn regions).
This strongly relates to #46 and should probably be handled together accordingly.
Similar to #50, the upstream addition of region
cn-north-1within boto 2.22.0 now triggers runtime failures due to this region requiring a dedicated account.While this issue is about
cn-*right now, it confirms my hunch back then that any dedicated handling will not scale, and a region neutral handling is also confirmed as the current upstream position in https://github.com/boto/boto/issues/1951#issuecomment-31493498.So in hindsight the
include/onlysolution derived from the AWS Tools for Windows PowerShell turns out to be short sighted, and also inconsistent with the existing--regionparameter in the first place:A better solution might be to expand this current substring handling to regular expressions, which would yield utmost flexibility, yet remain simple enough and explicit if so desired (e.g.
(us-east-1|us-west-1)) - the default here could then just be the universally accessible ones (i.e. excludegovandcnregions).