provider/aws: All open OpsWorks issues, with PRs, targeted for inclusion in v0.6.15?

[u2mejc]

This is a consolidation of every [known] OpsWorks issue broken v0.6.14, each with a PR, with the hope that we can get OpsWorks stable in 0.6.15! 🚀 Also if anyone sees a PR / Issue I missed, please let me know.

• provider/aws: OpsWorks stack creation brocken - Released in 0.6.15
  • This is a bad one, a PR merged caused a regression that broke OpsWorks for almost every OS except 12.04. 💥
  • Related: provider/aws: Support Windows OpsWorks Stacks #5569 AWS Opsworks Stack - Unable to set both default_os and configuration_manager_version #5905 AWS Opsworks Stack - Unable to create Linux Chef 12 stacks #5958 provider-aws: Creating Opsworks Stack fails with default OS Ubuntu 14.04 LTS and Chef version 11.10 #6221
  • PR to fix: aws/provider: Resolves DefaultOS and ConfigurationManager conflict #6244
• Roll up issue for known ignore_changes problems - Roll up issue for known ignore_changes problems #5627
  • Worth mentioning as is comes up in issues is:issue is:open opsworks, ignore_changes works well in my testing. ie:

    lifecycle {
        ignore_changes = ["custom_cookbooks_source.0.ssh_key"]
    }

• AWS Opsworks Rails App Layer ignores manage_bundler AWS Opsworks Rails App Layer ignores manage_bundler #5907
  • PR to fix: no PRs submitted yet
• providers/aws: add aws_s3_bucket resource region argument providers/aws: add aws_s3_bucket resource region argument #6051
  • Not directly a OpsWorks issue, but related because S3 bucket creation outside us-east-1 is broken when using OpsWork resources in the same modules path.
  • PR to fix: 6243 No pending PRs
• provider/aws : Opsworks fails on update provider/aws : Opsworks fails on update #6077 - Released in 0.6.15
  • This issues assumes that every stack will us custom cookbooks. With the growth and quality of the supermarket, this isn't true anymore and the bug breaks updates for stacks not using custom cookbooks.
  • PR to fix: Fix issue with with Opsworks and empty Custom Cook Book sources #6078 (checked off by @catsby)
• provider/aws: TestAccAWSOpsworksCustomLayer tests failing inconsistently provider/aws: TestAccAWSOpsworksCustomLayer tests failing inconsistently #6201
  • I also wasn't able to reproduce this issue, something uniqe with Paul's env. A wild guess on my part would be a deleted default VPC issue?

[janschumann]

@u2mejc As mentioned in #4419, some attributes of an aws_opsworks_application resource are not passed to the underlying go sdk for some reason. Or at least I believe that this is the case, as a manual call to the aws api works as documented.

E.g. the attribute document_root is always empty. That is when creating that resource and also when refreshing the state after editing that resource manually.

This might be related to #5907.

Can you confirm, that you can not reproduce this behavior?

[u2mejc]

Thank you @catsby!

@janschumann I wasn't able to reproduce it previously, I believe it's because I'm using custom layers only. I poked at the ruby issue briefly and it's a weird one. It actually sends the boolean mentioned in #5907 as a 1 instead of a true. Then when plan is ran again, it fails to compare that false doesn't match what is in the resource.

I'll poke at it tomorrow, but if you or anyone else has a lead on the issue, please shoot up a PR, I don't presently have one staged for that issue.

[u2mejc]

UPDATE: v0.6.15 has been released, and Opsworks support has been radically improved. Instance and stack creation are now supported, a nasty regression in creating stacks has been resolved, failing to update stacks was resolved, and plenty of other small feature / issues.

Still the biggest outstanding issue now is language or app specific layers are not being transmitted properly to AWS and silently fail to be properly diff'ed on subsequent runs. #5907

I'm also going to close the s3 issue PR. I'm not feeling good traction on wrapping my head around the issue, and I want to make sure that anyone who wants to work on the issue isn't turned away by seeing my open WIP.

[ericgoedtel]

@janschumann Were you able to find a fix to the problem regarding document_root? I am seeing a similar if not identical problem. terraform is not setting or fetching the value of document root and saving it to tfstate.

[janschumann]

UPDATE: as off 0.7.13 the document_root problem still exists. I will work on this now.

@u2mejc @ericgoedtel

[stack72]

What is the status of the rest of this ticket?

Paul

[janschumann]

@stack72 sorry, just seen this right now. I will try to figure out the status and also look if there are any other opsworks related issues.

[janschumann]

• AWS Opsworks Rails App Layer ignores manage_bundler AWS Opsworks Rails App Layer ignores manage_bundler #5907
  • PR to fix: Correct true and false OpsWorks string values to fix manage_bundler config bug #7219 (but reopened)
  • I will figure out, if I can work on that

All other issues, including all opsworks application issues regarding additional attributes (#10477) should be fixed.

[stack72]

the PR (#10669) from @janschumann shows that this can now be closed - thanks for all the work here @u2mejc and @janschumann :)

[ghost]

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.