Terraform-provider-google: Feature Request: google_endpoints_endpoint resource

Created on 9 Nov 2017  ·  10Comments  ·  Source: hashicorp/terraform-provider-google

_This issue was originally opened by @brising6 as hashicorp/terraform#16606. It was migrated here as a result of the provider split. The original body of the issue is below._


Terraform Version

terraform -v
Terraform v0.10.8

Feature Description

It'd be great to have a resource for creating google endpoints with app engine using terraform.

Actual Behavior

Provide endpoint config files as data templates then use terraform to inject information, such as the project id from other modules or state file outputs, and use the files to create google cloud endpoints.

References

https://cloud.google.com/endpoints/docs/

new-resource

Most helpful comment

Okay, Endpoints is really a feature of the ServiceManagement client, and the deploy is heavy on the client side, so this isn't likely to be ready until after the holidays. In any event, I'm on it.

All 10 comments

We'll need to do #638 to create google endpoints with app engine, but we can add endpoints support to compute engine, and expand it to app engine and kubernetes later.

Okay, Endpoints is really a feature of the ServiceManagement client, and the deploy is heavy on the client side, so this isn't likely to be ready until after the holidays. In any event, I'm on it.

Awesome, thanks for picking it up :)

I'm thinking that this will expose the names and addresses of the APIs configured, the DNS address of the service, and the names and addresses of any endpoints configured if they're nonstandard. It's going to have to run off a config file provided as per the Endpoints spec, like this example here: https://github.com/GoogleCloudPlatform/java-docs-samples/blob/master/endpoints/getting-started/openapi.yaml.

Can anyone think of anything else they'd need exposed?

We are using gRPC cloud endpoints as part of our Kubernetes Engine setup in Google Cloud.

Getting support for that as well would be great, I am available for testing if needed.

Glad you mentioned it! I'll see what can be done and report back. :)

Good news - it turned out to be pretty doable. @ean If you feel like it, it'd be nice if you would take a look at the documentation on PR #933 and let me know what you think about which attributes I've selected to make available. Please let me know if you would use anything I'm not exporting - there'll never be an easier time than now to add them in. :)

@ndmckinley thanks!

The provided attributes looks good. The only ones we use right now are config_id and dns_address, so out current use-case should at least be properly covered.

Great, glad to hear it. I'll go ahead and start code review and try to get that in soon. It might not make 1.5.0, it depends on when we cut that release, but I'll be pretty surprised if it's not in the release after that.

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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!

Was this page helpful?
0 / 5 - 0 ratings