Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Documentation about aws_dms_replication_instance seems wrong regarding replication_subnet_group_id #18086

Open
Imanuel-Mizrahi opened this issue Mar 14, 2021 · 3 comments
Labels
documentation Introduces or discusses updates to documentation. good first issue Call to action for new contributors looking for a place to start. Smaller or straightforward issues. service/dms Issues and PRs that pertain to the dms service.

Comments

@Imanuel-Mizrahi
Copy link

Inside the docs of aws_dms_replication_instance, there seems to be a mistake.
For the parameter: "replication_subnet_group_id", the value is: aws_dms_replication_subnet_group.test.id.
However, inside the docs for "aws_dms_replication_subnet_group", there is no 'id' field at all!
I guess that the value should be: "replication_subnet_group_id" instead, as this one is a required field for aws_dms_replication_subnet_group.

@github-actions github-actions bot added the needs-triage Waiting for first response or review from a maintainer. label Mar 14, 2021
@anGie44 anGie44 added documentation Introduces or discusses updates to documentation. and removed needs-triage Waiting for first response or review from a maintainer. labels Mar 16, 2021
@anGie44
Copy link
Contributor

anGie44 commented Mar 16, 2021

Hi @Imanuel-Mizrahi , thank you raising this issue. While the aws_dms_replication_instance resource documentation is correct to reference the aws_dms_replication_subnet_group.test.id, you've raised a good point in that the aws_dms_replication_subnet_group documentation is missing details on the id attribute, which happens to be the replication_subnet_group_id as seen here:

d.SetId(d.Get("replication_subnet_group_id").(string))

Adding a row with the id attribute in the documentation should fix this 👍

@anGie44 anGie44 added the good first issue Call to action for new contributors looking for a place to start. Smaller or straightforward issues. label Mar 16, 2021
@Imanuel-Mizrahi
Copy link
Author

Imanuel-Mizrahi commented Mar 16, 2021

Thank you @anGie44 !!
So, now I come to the part how it all began...
I was using this TF template, based on the docs:

resource "aws_dms_replication_subnet_group" "test" {
  replication_subnet_group_description = "Test replication subnet group"
  replication_subnet_group_id          = "test-dms-replication-subnet-group-tf"

  subnet_ids = [
    aws_subnet.nondefault_1.id,
    aws_subnet.nondefault_2.id
  ]

  tags = {
    Name = "test"
  }
}

resource "aws_dms_replication_instance" "test" {
  allocated_storage            = 20
  apply_immediately            = true
  auto_minor_version_upgrade   = true
  multi_az                     = true
  preferred_maintenance_window = "sun:10:30-sun:14:30"
  publicly_accessible          = true
  replication_instance_class   = "dms.t2.micro"
  replication_instance_id      = "test-dms-replication-instance-tf"
  replication_subnet_group_id  = aws_dms_replication_subnet_group.test.id

  tags = {
    Name = "test"
  }

I was sure that the "terraform plan" will import the replication_subnet_group_id from the "aws_dms_replication_subnet_group" resource, so the "aws_dms_replication_instance" resource will show it as the actual name ("test-dms-replication-subnet-group-tf"), once I run the plan.
However, the result was:

Terraform will perform the following actions:

  # aws_dms_replication_instance.test will be created
  + resource "aws_dms_replication_instance" "test" {
      + allocated_storage                = 20
      + apply_immediately                = true
      + auto_minor_version_upgrade       = true
      + availability_zone                = (known after apply)
      + engine_version                   = (known after apply)
      + id                               = (known after apply)
      + kms_key_arn                      = (known after apply)
      + multi_az                         = true
      + preferred_maintenance_window     = "sun:10:30-sun:14:30"
      + publicly_accessible              = true
      + replication_instance_arn         = (known after apply)
      + replication_instance_class       = "dms.t2.micro"
      + replication_instance_id          = "test-dms-replication-instance-tf"
      + replication_instance_private_ips = (known after apply)
      + replication_instance_public_ips  = (known after apply)
      + replication_subnet_group_id      = (known after apply)
      + tags                             = {
          + "Name" = "test"
        }
      + vpc_security_group_ids           = (known after apply)
    }

Note that replication_subnet_group_id will only be known after apply.

Now, if I change the TF to use the replication_subnet_group_id from resource "aws_dms_replication_subnet_group", as follows:

resource "aws_dms_replication_instance" "test" {
  allocated_storage            = 20
  apply_immediately            = true
  auto_minor_version_upgrade   = true
  multi_az                     = true
  preferred_maintenance_window = "sun:10:30-sun:14:30"
  publicly_accessible          = true
  replication_instance_class   = "dms.t2.micro"
  replication_instance_id      = "test-dms-replication-instance-tf"
  replication_subnet_group_id  = aws_dms_replication_subnet_group.test.replication_subnet_group_id

  tags = {
    Name = "test"
  }

}

The plan result is as expected, and the data is imported:

Terraform will perform the following actions:

  # aws_dms_replication_instance.test will be created
  + resource "aws_dms_replication_instance" "test" {
      + allocated_storage                = 20
      + apply_immediately                = true
      + auto_minor_version_upgrade       = true
      + availability_zone                = (known after apply)
      + engine_version                   = (known after apply)
      + id                               = (known after apply)
      + kms_key_arn                      = (known after apply)
      + multi_az                         = true
      + preferred_maintenance_window     = "sun:10:30-sun:14:30"
      + publicly_accessible              = true
      + replication_instance_arn         = (known after apply)
      + replication_instance_class       = "dms.t2.micro"
      + replication_instance_id          = "test-dms-replication-instance-tf"
      + replication_instance_private_ips = (known after apply)
      + replication_instance_public_ips  = (known after apply)
      + replication_subnet_group_id      = "test-dms-replication-subnet-group-tf"
      + tags                             = {
          + "Name" = "test"
        }
      + vpc_security_group_ids           = (known after apply)
    }

I am pretty new with github, should I create a new issue for this...?

Appreciate your assistance @anGie44 !!

@Imanuel-Mizrahi
Copy link
Author

Turns out this behavior changes, depends on the terraform version you use.
So, using v0.12.30 the plan include the information correctly.
I think that initially, I was running with a higher version while experiencing the issue with the plan version 14 I think.

@ewbankkit ewbankkit added the service/dms Issues and PRs that pertain to the dms service. label Jun 2, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Introduces or discusses updates to documentation. good first issue Call to action for new contributors looking for a place to start. Smaller or straightforward issues. service/dms Issues and PRs that pertain to the dms service.
Projects
None yet
Development

No branches or pull requests

3 participants