Expose GCP project_id / network_name for network peering

[atsui-bay1]

Affected Resource(s)

Please list the resources as a list, for example:

• rediscloud_subscription (GCP)

It would be useful if the rediscloud_subscription resource exposed the gcp_project_id and gcp_network_name needed to make a GCP network peering. This data seems to only be exposed on the UI when making a peering connection manually, and thus defeats the ability to generate a full subscription/peering setup within Terraform.

[nir-redis]

Hi,
Thanks for raising this issue. We recently solved a bug in our API that prevented the peering with GCP environments, has this been raised in relation to that issue? You should be able to create a peering through terraform without UI actions

[atsui-bay1]

I can successfully create the peering through Terraform, however I had to pull the gcp_project_id and gcp_network_name from the UI and fill them into terraform. This issue is to streamline that process by exposing those two parameters directly to terraform. For example, I would like to be able to do the following:

resource "rediscloud_subscription" "example" {
....
}

resource "rediscloud_subscription_peering" "example" {
   subscription_id = rediscloud_subscription.example.id
   provider = "GCP"
   gcp_project_id = rediscloud_subscription.example.gcp_project_id
   gcp_network_name = rediscloud_subscription.example.gcp_network_name
}

I did notice that networking_vpc_id is exposed (I think I missed it before), but the Project ID for GCP seems hidden from this restriction ((using Cloud Account ID = 1 implies using Redis Labs internal cloud account). Note that a GCP subscription can be created only with Redis Labs internal cloud account)

[danielarbiv]

Hi @atsui-bay1 ,

Looks like we already support exposing those two fields in Cloud-API:

• projectUid
• networkName

After creating a GCP VPC peering, one can get those values from our GET/Subscriptions/{subscriptionId}/peering endpoint

This is an example for a response:

{
  "taskId": "e8b83db4-efcc-450c-862a-70eb6333c698",
  "commandType": "vpcPeeringGetRequest",
  "status": "processing-completed",
  "description": "Request processing completed successfully and its resources are now being provisioned / de-provisioned.",
  "timestamp": "2021-12-09T14:24:38.447548Z",
  "response": {
    "resourceId": 129138,
    "resource": {
      "peerings": [
        {
          "vpcPeeringId": 1297,
          "projectUid": "cloud-api-256112",
          "networkName": "cloud-api-vpc-peering-test",
          "redisProjectUid": "q29b7889c8a2ae6cb-tp",
          "redisNetworkName": "c298956-us-central1-mz-rlrcp",
          "cloudPeeringId": "redislabs-peering-16da2a40-a78",
          "status": "inactive"
        }
      ]
    }
  },
  "_links": {
    "self": {
      "href": "http://localhost:8081/v1/tasks/e8b83db4-efcc-450c-862a-70eb6333c698",
      "type": "GET"
    }
  }
}

If something is still not clear, fell free to reach.

[atsui-bay1]

Hi @danielarbiv,

The issue is that the projectId is not exposed in any Terraform resource output or attribute, and specifically not exposed early enough to use as a reference when creating the peering connection. Being able to query the projectId after creating the peering is not helpful in this case.