Terraform: provider/aws: Use a endpoint where a stack lives for all opsworks resources

[nabeken]

I open a new issue because it's a case which described in https://github.com/hashicorp/terraform/pull/13024#issuecomment-292308243

Terraform Version

Probably 0.9.2

Affected Resource(s)

• resource_aws_opsworks_application
• resource_aws_opsworks_custom_layer
• resource_aws_opsworks_ganglia_layer
• resource_aws_opsworks_haproxy_layer
• resource_aws_opsworks_instance
• resource_aws_opsworks_java_app_layer
• resource_aws_opsworks_memcached_layer
• resource_aws_opsworks_mysql_layer
• resource_aws_opsworks_nodejs_app_layer
• resource_aws_opsworks_permission
• resource_aws_opsworks_php_app_layer
• resource_aws_opsworks_rails_app_layer
• resource_aws_opsworks_rds_db_instance
• resource_aws_opsworks_static_web_layer
• resource_aws_opsworks_user_profile

It looks like resource_aws_opsworks_stack has been patched in 0.9.2.

Expected Behavior

Except resource_aws_opsworks_stack resources should go to a endpoint where a stack lives too.

Actual Behavior

Only resource_aws_opsworks_stack go to a endpoint where it lives.

References

• https://github.com/hashicorp/terraform/pull/13024#issuecomment-292308243
• https://github.com/hashicorp/terraform/issues/12842

[zencodeuk]

Can we just configure the endpoint on the provider in the same way as Dynamo, Iam, Ec2 etc?

https://github.com/hashicorp/terraform/blob/master/builtin/providers/aws/config.go#L250

[jdirwin]

This bug prevents us (and presumably most people already using terraform and opsworks) from upgrading to 0.9.

[GuiSim]

If it's simpler, could we perhaps rollback the changes so that the behavior is "unbroken"? It's not perfect but right now I feel like anyone who's using OpsWorks is stuck and can't update.

[GuiSim]

I hate to bump this again but... we've been stuck on v0.8.8 for a while now (10 versions behind latest release).

Multiple solutions have been proposed but I'd like the opinion of the main collaborators on the best resolution to this issue.

The proposed solutions:

• Rollback the initial commit (https://github.com/hashicorp/terraform/pull/13024)
• Do as @zencodeuk suggested and configure the endpoint
• Apply the changes made in https://github.com/hashicorp/terraform/pull/13024 to other Terraform resources

@catsby as the original author of the PR, do you have any opinion on this?

I'd be willing to test and contribute a fix with some guidance.

[catsby]

Hey all sorry for the silence – I think the 3rd option is the right path forward. Rolling back still leaves the broken behavior, and the 2nd option locks people in to that region for all Opsworks resources globally.

You could likely extract this attribute out kind of like tagsSchema() to avoid some duplication in the schema, or at least enforce consistency

[zencodeuk]

@catsby Just to clarify the solution. It leaves functionality as is for anyone that has adopted since with regional stacks (use default user configured AWS region). However it gives anyone pre 0.9 to override and set us-east-1 their region for legacy.

[catsby]

@zencodeuk I believe so, which I think is what we want, right? Am I missing something?

[zencodeuk]

@catsby dont thinks so :+1: I was just clarifying the solution I proposed (the 2nd) that it wouldn't lock anyone into global resources as the behaviour stays as 0.9 unless you override the opsworks region (to us-east-1 for any 0.8 users)

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.