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

Memorystore Redis should not recreate instance while using named reserved_ip_range #11243

Closed
devoldoak opened this issue Mar 9, 2022 · 6 comments

Comments

@devoldoak
Copy link

devoldoak commented Mar 9, 2022

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request.
  • Please do not leave +1 or me too comments, they generate extra noise for issue followers and do not help prioritize the request.
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment.
  • If an issue is assigned to the modular-magician user, it is either in the process of being autogenerated, or is planned to be autogenerated soon. If an issue is assigned to a user, that user is claiming responsibility for the issue. If an issue is assigned to hashibot, a community member has claimed the issue already.

Terraform Version

Terraform v1.1.4
on linux_amd64

  • provider registry.terraform.io/hashicorp/google v4.13.0 (signed by HashiCorp)

Affected Resource(s)

  • google_redis_instance

Terraform Configuration Files

resource "google_redis_instance" "cache" {
  name           = "memory-cache-myproject"
  memory_size_gb = 1
  region = "europe-west1"

  authorized_network = "projects/project-vpc-shared-test/global/networks/vpc-shared-test"
  connect_mode       = "PRIVATE_SERVICE_ACCESS"
  display_name      = "myproject_cache"
  reserved_ip_range = "test-redis-private-ip"
}

reserved_ip_range is a named private range for 10.10.0.0/16

Expected Behavior

Running terraform apply command should not recreate instance without any change. The reserved_ip_range should store the name of the range instead of the computed /29 range from the initial range size.

Actual Behavior

Running terraform apply without any change require recreating instance because of reserved_ip_range named value.

# module.redis_ressources.google_redis_instance.cache must be replaced
-/+ resource "google_redis_instance" "cache" {
      + alternative_location_id  = (known after apply)
      + auth_string              = (sensitive value)
      ~ create_time              = "2022-03-09T09:39:30.140718732Z" -> (known after apply)
      ~ current_location_id      = "europe-west1-b" -> (known after apply)
      ~ host                     = "10.10.0.3" -> (known after apply)
      ~ id                       = "projects/myproject-test/locations/europe-west1/instances/memory-cache-myproject" -> (known after apply)
      ~ location_id              = "europe-west1-b" -> (known after apply)
        name                     = "memory-cache-myproject"
      ~ persistence_iam_identity = "serviceAccount:[email protected]" -> (known after apply)
      ~ port                     = 6379 -> (known after apply)
      ~ project                  = "myproject-test" -> (known after apply)
      - redis_configs            = {} -> null
      ~ redis_version            = "REDIS_6_X" -> (known after apply)
      ~ reserved_ip_range        = "10.10.0.0/29" -> "test-redis-private-ip" # forces replacement
      ~ server_ca_certs          = [] -> (known after apply)
        # (9 unchanged attributes hidden)
    }

b/302797595

@devoldoak devoldoak added the bug label Mar 9, 2022
@c2thorn c2thorn self-assigned this Mar 9, 2022
@avneesh-taos
Copy link

avneesh-taos commented Jun 24, 2022

Facing same issue of recreation of redis instance . If i use the cidr range which is mentioned in the terraform docs for the reserved_ip_range , it throws error and not allow to create redis instance
Error: Error creating Instance: googleapi: Error 400: Field instance.reserved_ip_range must match the name of an allocated IP address range associated with the private service connection. To see address ranges for your project, see https://cloud.google.com/vpc/docs/configure-private-services-access#listing_allocated_ip_address_ranges.

However, by using the subnet name, terraform allows to create the redis instance but while running the plan again , it recreates the instance as reserved_ip_range is expected cidr range and it was created with subnet name.

@devoldoak
Copy link
Author

We found a workaroundby referring reserved IP range using datasource first and adding network id to reserved_ip_range

data "google_compute_network" "redis-network" {
  name = "test-redis-private-ip"
}

resource "google_redis_instance" "cache" {
  name           = "memory-cache-myproject"
  memory_size_gb = 1
  region = "europe-west1"

  authorized_network = "projects/project-vpc-shared-test/global/networks/vpc-shared-test"
  connect_mode       = "PRIVATE_SERVICE_ACCESS"
  display_name      = "myproject_cache"
  reserved_ip_range = data.google_compute_network.redis-network.id
}

@abhilashindulkar
Copy link

I was able to resolve the issue through following code. I fetched global allocated IP range through data access block which is being passed as a named attribute to reserved_ip_range while provisioning memorystore - redis instance.

data "google_compute_network" "redis-network" {
  name = "custom-vpc"
}

data "google_compute_global_address" "service_range" {
  name = "psa"
}

resource "google_service_networking_connection" "private_service_connection" {
  network                 = data.google_compute_network.redis-network.id
  service                 = "servicenetworking.googleapis.com"
  reserved_peering_ranges = [data.google_compute_global_address.service_range.name]
}

module "memorystore" {
  source             = "terraform-google-modules/memorystore/google"
  version            = "~> 7.0"
  name               = "private-cache"
  project            = var.project_id
  display_name       = "Terraform Test Instance"
  region             = var.region
  tier               = "BASIC"
  enable_apis        = true
  authorized_network = data.google_compute_network.redis-network.id
  connect_mode       = "PRIVATE_SERVICE_ACCESS"
  reserved_ip_range  = data.google_compute_global_address.service_range.name
  read_replicas_mode = "READ_REPLICAS_DISABLED"
  memory_size_gb     = 1
}

Feels like either the documentation is outdated or incorrect. When i looked into Troubleshooting Networking Issues, with private service access connect mode on, you can't specify reserved_ip_range which i hadn't faced.

But there is an another doc that says if there are multiple IP address ranges allocated for private services access, you can use the --reserved-ip-range gcloud flag to choose which allocated ranges to use when creating your Redis instance. Refer Custom ranges with private services access

Note - Even if you had allocated larger IP CIDR block range (for instance - 10.x.0.0/22), Redis instance will only make use of /29 CIDR block range.

@github-actions github-actions bot added forward/review In review; remove label to forward service/redis-instance labels Aug 17, 2023
@roaks3 roaks3 removed the forward/review In review; remove label to forward label Sep 29, 2023
@miroswan
Copy link

miroswan commented Oct 26, 2023

I believe we can close this one. It was resolved in #7429. I've verified this by using a named value for reserve_ip_range and executing terraform apply twice consecutively; the second run generated no changes.

@c2thorn
Copy link
Collaborator

c2thorn commented Oct 30, 2023

closed with GoogleCloudPlatform/magic-modules#7429

@c2thorn c2thorn closed this as completed Oct 30, 2023
Copy link

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 30, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

7 participants