AWS Opsworks Rails App Layer ignores manage_bundler

[ldhertert]

Any rails app later created by terraform has "Install and manage Bundler" set to "no", regardless of the value placed in the terraform config. Using terraform v0.6.14.

[apparentlymart]

Thanks for reporting this, @ldhertert.

I did some initial investigation here but didn't have time yet to dig deep. The rest of this comment is just some notes for future-me or anyone else that wants to try to debug this:

The opsworks layer attributes are implemented in a generic, schema-driven way so I think there are two obvious ways in which this could be broken:

• The attribute name Terraform is using in the underlying API call is incorrect. This would mean it would affect only this attribute on this layer type.
• The way Terraform is serializing boolean values is incorrect. This would mean that all of the boolean attributes could be broken across all layer types, which seems less likely since I remember seeing other booleans work during my earlier testing.

The documentation shows that there is indeed an attribute called ManageBundler, which is the name that Terraform is using.

As far as I can tell there is no real documentation for what values are expected for each attribute, so the values used by Terraform were figured out by trying things in the UI and then checking how they appeared in the API responses. However, it's possible that there are some inconsistencies in these that I didn't catch in the original implementation work.

When I get a chance I'll try to repro this and see how what Terraform is writing is different to what the AWS console writes when populating this attribute.

[janschumann]

I think I found a similar bug while testing #4419 (opsworks app). There some optional arguments that can be passed to the aws api depending on the application type. The issue is that the attributes value is always empty, regardless of what was configured.

See the following example, where document_root is configured:

resource "aws_opsworks_application" "app" {
  name              = "${var.name}"
  short_name        = "${var.short_name}"
  type              = "other"
  stack_id          = "${var.stack_id}"
  app_source        = {
    type = "${var.source_type}"
    url = "${var.source_url}"
    revision = "${var.source_revision}"
    ssh_key = "${file("${var.deploy_ssh_key_file}")}"
  }
  document_root = "web"
}

Even if the resource was modified manually by setting the document root parameter to any string, terraform plan always reports this resource to be changed:

~ aws_opsworks_application.app
    document_root:        "" => "web"

The document_root parameter should be passed to the sdk as a member of an Attributes map just like it is done in the rails layer resource. Is this probably related?

[u2mejc]

I poked at this a little today. First issue is here in opsworks_layers.go

var (
   opsworksTrueString  = "1"
   opsworksFalseString = "0"
)

Should be:

var (
   opsworksTrueString  = "true"
   opsworksFalseString = "false"
)

That small change actually resolves @ldhertert initial issue. If you terraform apply, it works. But after digging, the root issue is the live (remote AWS) layer attributes are not being written to the statefile. This breaks changing anything inside the attributes map and then the eval loop fails to see any changes. I poked around some, but it didn't bubble up to me yet. I'll poke at it more as time allows, but I don't have a patch staged at this time.

[iroller]

Stuck on the same issue with manage_bundler here

[stack72]

This is fixed via #7219

[u2mejc]

@stack72 That close may be a little premature... Did you see why I didn't take credit for a two line PR previously (above)?

[u2mejc]

@stack72 Please reopen this, my code that dlanner created the PR for doesn't fix this issue.

[stack72]

Reopened on request :)

[u2mejc]

Thx! 🍻

[janschumann]

@u2mejc @stack72 i added a test to verify that the manage_bundler attribute is set correctly. During the test I also verified the correct behavior via the AWS Console. I think that this issue can be closed.

Do you want me to create a PR for the commit?

[stack72]

@janschumann if that PR will close this PR then I would love that :)

[stack72]

Verified that this works via #10669

[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.