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

Provide endpoint for AWS step functions #7735

Closed
brettcooper opened this issue Feb 26, 2019 · 3 comments
Closed

Provide endpoint for AWS step functions #7735

brettcooper opened this issue Feb 26, 2019 · 3 comments
Labels
enhancement Requests to existing resources that expand the functionality or scope. provider Pertains to the provider itself, rather than any interaction with AWS.
Milestone

Comments

@brettcooper
Copy link

brettcooper commented Feb 26, 2019

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

I am trying to setup LocalStack with AWS Step Functions, but cannot apply my stepfunctions.tf file due to the following error: "Error: provider.aws: endpoints.0: invalid or unknown key: sfn"

It would be helpful to be able to define the AWS Step Functions endpoint.

Potential Terraform Configuration

providers.tf:

# Oregon
terraform {
  required_version = "0.11.11"
}

provider "aws" {

  skip_credentials_validation = true
  skip_metadata_api_check     = true
  s3_force_path_style         = true
  access_key                  = "mock_access_key"
  secret_key                  = "mock_secret_key"

  version = "1.40"
  region = "us-west-2"
  insecure = true

  # https://www.terraform.io/docs/providers/aws
  # https://github.com/localstack/localstack
  endpoints {
    # acm
    apigateway     = "https://localstack:4567"
    cloudformation = "https://localstack:4581"
    cloudwatch     = "https://localstack:4582"
    # cloudwatchevents
    # cloudwatchlogs
    # devicefarm
    dynamodb       = "https://localstack:4569"
    # ec2
    # autoscaling
    # ecr
    # ecs
    # elb
    # efs
    es             = "https://localstack:4578"
    # iam
    kinesis        = "https://localstack:4568"
    # kms
    lambda         = "https://localstack:4574"
    # r53
    # rds
    s3             = "https://localstack:4572"
    # s3control
    sns            = "https://localstack:4575"
    sqs            = "https://localstack:4576"
    # sts
    ssm            = "https://localstack:4583"
    sfn            = "https://localstack:4585"
  }
}

stepfunctions.tf

resource "aws_sfn_state_machine" "SimpleDelayStateMachine" {
  name     = "SimpleDelayStateMachine"
  role_arn = "arn:aws:iam::000000000000:role/service-role/StatesExecutionRole"

  definition = <<EOF
{
   "StartAt":"start",
   "States":{
      "start":{
         "TimestampPath":"$.wait_until",
         "Next":"next",
         "Type":"Wait"
      },
      "next":{
         "End":true,
         "Resource":"arn:aws:lambda:us-west-2:000000000000:function:stepfunction-lambda-bridge",
         "Type":"Task"
      }
   }
}
EOF
}

References

@brettcooper brettcooper added the enhancement Requests to existing resources that expand the functionality or scope. label Feb 26, 2019
@bflad bflad added the provider Pertains to the provider itself, rather than any interaction with AWS. label Mar 26, 2019
bflad added a commit that referenced this issue Mar 27, 2019
Historically, we have treated endpoint customization as an optional enhancement when adding service clients to the provider. Over time, the necessity of service endpoint customization has changed including:

* FIPS 140-2 compliant endpoints
* AWS C2S and SC2S potential usage
* AWS Snowball potential usage
* Local testing solutions such as LocalStack
* Rare incorrect default endpoint information provided by the AWS Go SDK

This change enables all existing service clients to support endpoint customization and going forward we can include this support by default. If the AWS Go SDK provides a better customization method in the future or defines environment variable support, we can revisit this in the future. We may also choose to further optimize endpoint handling via new provider configurations (e.g. use all known FIPS 140-2 endpoints).

Endpoint service naming is based on existing configuration. Where we do not have a prior configuration, we opt for using the AWS CLI service naming minus any hyphens. We also deprecate our own naming for `kinesis_analytics` and `r53` with `kinesisanalytics` and `route53` respectively for consistency.

References:

* https://aws.amazon.com/compliance/fips/
* https://aws.amazon.com/federal/us-intelligence-community/
* https://aws.amazon.com/snowball/
* https://docs.aws.amazon.com/cli/latest/index.html
* https://localstack.cloud/
* #7735
* #8007
* #7985
* #4967
* #4670
* #3941
* #3888
* #3608
@bflad bflad added this to the v2.5.0 milestone Apr 1, 2019
pull bot pushed a commit to KernelPanicAUS/terraform-provider-aws that referenced this issue Apr 1, 2019
Historically, we have treated endpoint customization as an optional enhancement when adding service clients to the provider. Over time, the necessity of service endpoint customization has changed including:

* FIPS 140-2 compliant endpoints
* AWS C2S and SC2S potential usage
* AWS Snowball potential usage
* Local testing solutions such as LocalStack
* Rare incorrect default endpoint information provided by the AWS Go SDK

This change enables all existing service clients to support endpoint customization and going forward we can include this support by default. If the AWS Go SDK provides a better customization method in the future or defines environment variable support, we can revisit this in the future. We may also choose to further optimize endpoint handling via new provider configurations (e.g. use all known FIPS 140-2 endpoints).

Endpoint service naming is based on existing configuration. Where we do not have a prior configuration, we opt for using the AWS CLI service naming minus any hyphens. We also deprecate our own naming for `kinesis_analytics` and `r53` with `kinesisanalytics` and `route53` respectively for consistency.

References:

* https://aws.amazon.com/compliance/fips/
* https://aws.amazon.com/federal/us-intelligence-community/
* https://aws.amazon.com/snowball/
* https://docs.aws.amazon.com/cli/latest/index.html
* https://localstack.cloud/
* hashicorp#7735
* hashicorp#8007
* hashicorp#7985
* hashicorp#4967
* hashicorp#4670
* hashicorp#3941
* hashicorp#3888
* hashicorp#3608
@bflad
Copy link
Contributor

bflad commented Apr 1, 2019

Support for configuring the endpoint has been merged and will release with version 2.5.0 of the Terraform AWS Provider likely later this week. 👍

provider "aws" {
  # ... potentially other provider configuration ...

  endpoints {
    # ... potentially other endpoint configuration ...
    stepfunctions  = "http://localhost:4585"
  }
}

@bflad bflad closed this as completed Apr 1, 2019
@bflad
Copy link
Contributor

bflad commented Apr 5, 2019

This has been released in version 2.5.0 of the Terraform AWS provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

@ghost
Copy link

ghost commented Mar 30, 2020

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. Thanks!

@ghost ghost locked and limited conversation to collaborators Mar 30, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement Requests to existing resources that expand the functionality or scope. provider Pertains to the provider itself, rather than any interaction with AWS.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants