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

Bug: timescale_peering_connection provisioned_id is null before refresh #206

Open
eddyfussel opened this issue Jun 12, 2024 · 1 comment

Comments

@eddyfussel
Copy link

Hi, I'm using this provider to create a timescale database for testing the saas product. Since we would like to use a private endpoint, I use the timescale_peering_connection resource to peer with our vpc.

If I place my aws_vpc_peering_connection_accepter directly next to the timescale_peering_connection I can directly use the provisioned_id as an input for the vpc_peering_connection_id

Here is some example code

resource "timescale_peering_connection" "peering" {
  peer_account_id  = var.aws_account_id
  peer_region_code = var.aws_region
  peer_vpc_id      = var.vpc_id
  timescale_vpc_id = timescale_vpcs.vpc.id
}

resource "aws_vpc_peering_connection_accepter" "accepter_to_timescale" {
  vpc_peering_connection_id = timescale_peering_connection.peering.provisioned_id
  auto_accept               = true

  accepter {
    allow_remote_vpc_dns_resolution = true
  }

  tags = {
    Name        = "timescale/${timescale_vpcs.vpc.name}"
    description = "Peer ${var.aws_account_id}/${var.vpc_id} to timescale/${timescale_vpcs.vpc.name} for project_id ${timescale_vpcs.vpc.project_id}"
    side        = "accepter"
  }
}

However this is not working, as get following error that indicates, that the provisioned-id is null.

│ Error: Missing required argument
│
│   with aws_vpc_peering_connection_accepter.accepter_to_timescale,
│   on main.tf line 14, in resource "aws_vpc_peering_connection_accepter" "accepter_to_timescale":
│   14:   vpc_peering_connection_id = timescale_peering_connection.peering.provisioned_id
│
│ The argument "vpc_peering_connection_id" is required, but no definition was
│ found.

To proof that I directly pulled the state from terraform by executing terraform console

❯ terragunt console
zsh: command not found: terragunt
❯ terragrunt console
INFO[0000] Terragrunt Cache server is listening on 127.0.0.1:50798
INFO[0000] Start Terragrunt Cache server
> timescale_peering_connection.peering
{
  "error_message" = tostring(null)
  "id" = tonumber(null)
  "peer_account_id" = "0123456789"
  "peer_cidr" = tostring(null)
  "peer_region_code" = "eu-central-1"
  "peer_vpc_id" = "vpc-012345467890"
  "provisioned_id" = tostring(null)
  "status" = tostring(null)
  "timescale_vpc_id" = 1234
  "vpc_id" = tostring(null)
}
> exit

Executing the apply again I get a change on the resource and the code starts working.

  # timescale_peering_connection.peering has changed
  ~ resource "timescale_peering_connection" "peering" {
      + provisioned_id   = "pcx-0123456789"
        # (4 unchanged attributes hidden)
    }

I would expect this to work, as the resource aws_vpc_peering_connection from aws to create a vpc peering between multiple vpcs is waiting until there is the pcx-.. available.

I've tried to update my code to add a delay, unfortunately that wasn't successful.

resource "timescale_peering_connection" "peering" {
  peer_account_id  = var.aws_account_id
  peer_region_code = var.aws_region
  peer_vpc_id      = var.vpc_id
  timescale_vpc_id = timescale_vpcs.vpc.id

  # We delay here the creation of the peering, as the provisioned_id is null until aws is ready
  # and unfortunatly the provisioner directly gives us this null object back without waiting for
  # aws to be ready. Otherwise we can't use this in aws_vpc_peering_connection_accepter object.
  provisioner "local-exec" {
    command = "sleep 90"
  }
}

I also have here a log file to see the commands I've executed:
bug_timescale_provider_retracted.txt

Thanks in advance for any feedback, idea or help.

BR eddyfussel

@Khyme
Copy link
Contributor

Khyme commented Jun 12, 2024

Hello @eddyfussel,
I encountered the same issue myself when developing it, and had some issues fixing it.
IIRC, the code handling the timescale peering connection doesn't surface the provisioned-id so I think it needs wider code change on our end I didn't have the opportunity to, so released that half way done.
I'm sorry for the inconvenience.

As for when this might be fixed, I think this provider will not see some love again until Q3/4.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants