[provider] Implement endpoints

[lblackstone]

The endpoints parameter is not yet implemented.

Please upvote this issue if you need this feature. This helps us to determine roadmap priorities.

[ffMathy]

This is super useful for our integration tests, which are running against Localstack (simulated AWS environment) locally.

Also, this is now the top-voted issue 😏

[chris-stetter]

This is super useful for our integration tests, which are running against Localstack (simulated AWS environment) locally.

Also, this is now the top-voted issue 😏

Due to the same reason we cannot use native unfortunately.

[cabeaulac]

This just bit me with our Localstack integration.

[mikhailshilkov]

I'd love to engage to potential customers of this feature to understand the exact requirements and expectation from it. I don't think we can map the configuration parameter from AWS Classic 1:1.

To the contrary to the classic provider, AWS Native has a single endpoint for all resource operations: AWS Cloud Control API. Do folks want to override that single endpoint? Or is there configuration beyond that?

[sverch]

It looks like terraform allows for overriding just that api, and localstack seems to support it. I suspect that pointing requests to the local endpoint would do it, and the local service should handle it properly if it's truly emulating the aws API.

[mikhailshilkov]

It looks like terraform allows for overriding just that api

Yes, Terraform's implementation is notably different from AWS Native. They use direct service endpoints, while our native provider goes through Cloud Control API.

[sverch]

Do you mean that behind the scenes they are using the service endpoints to implement the cloud control api resource, or do you mean that rather than implementing it as a single resource, the AWS Native implementation provides a higher level API that routes to that underneath?

I would imagine that ultimately the request payload is a cloud control API object that is sent to the endpoint, where the object itself has service information. If that endpoint is a local service like localstack, I'd expect localstack to know how to interpret that request properly and "create" that resource in its local state.

[mikhailshilkov]

behind the scenes they are using the service endpoints to implement the cloud control api resource

I wasn't talking about aws_cloudcontrolapi_resource specifically. I think what this issue is asking for is being able to set a custom endpoint e.g. for s3, or for ecs, etc - a custom endpoint per AWS service.

I would imagine that ultimately the request payload is a cloud control API object that is sent to the endpoint, where the object itself has service information. If that endpoint is a local service like localstack, I'd expect localstack to know how to interpret that request properly and "create" that resource in its local state.

Yeah, we could allow you to override the Cloud Control API endpoint specifically. So, it would be a single endpoint value to set. Is that what you are asking for?

[sverch]

I wasn't talking about aws_cloudcontrolapi_resource specifically. I think what this issue is asking for is being able to set a custom endpoint e.g. for s3, or for ecs, etc - a custom endpoint per AWS service.

That's true, as the issue description is written, but my understanding of what you're saying is that pulumi implements the creation of those resources by converting them to requests to the cloud control API, is that right?

Yeah, we could allow you to override the Cloud Control API endpoint specifically. So, it would be a single endpoint value to set. Is that what you are asking for?

That's correct. I can't speak for others, but I use this as a "local test mode", so I either set all endpoints to the local service, or none of them, even when I have the ability to set them one at a time.

It's hard to think of a use case where I want some requests going to AWS, and some requests going to a local endpoint depending on the resource. If someone did have that use case, I believe they could work around it by creating different providers for different situations (e.g., a "myCustomS3Deployment" provider that they use only when creating s3 resources).