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

How to Handle AWS Spot Instance args (tags, etc.) #6791

Closed
johnnyshields opened this issue May 20, 2016 · 4 comments
Closed

How to Handle AWS Spot Instance args (tags, etc.) #6791

johnnyshields opened this issue May 20, 2016 · 4 comments

Comments

@johnnyshields
Copy link

johnnyshields commented May 20, 2016

This is a dupe of issue #3263 and PR #4380. I am raising a new issue because I'd like to revisit the problem and agree on an approach with the Terraform team.

The Problem

  • We need to set tags on AWS spot instances.
  • The Terraform schema contains a spot_instance_request resource. A aws_spot_instance_request is not an "instance" itself, rather it is a request to Amazon to generate an instance.
  • The Terraform schema allows setting tags on aws_spot_instance_request, however, the tags are not forwarded by AWS to the actual instance when the request in fulfilled (see: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html)

Possible Solutions

  1. Interpret tags on aws_spot_instance_request to mean the tags to set on the instance created when the spot request is fulfilled. This is what PR provider/aws: tag the spot instance. #4380 does.
  2. Add an instance_args node to the aws_spot_instance_request resource which allows various args like tags to be set by Terraform on the instance after fulfillment.
  3. Enhance the aws_instance to have new fields is_spot_instance, spot_price, spot_type etc. If these are set, then Terraform uses a spot instance request workflow to initialize the instance. This approach will require the most effort but is ultimately the most friendly / least surprising to the developer in my opinion--many AWS-related libraries use this abstraction pattern.
  4. Introduce a new resource aws_spot_instance which behaves as described in config: require blocks for upstream dependencies #3, to avoid changing the aws_instance object.
@johnnyshields
Copy link
Author

johnnyshields commented May 20, 2016

According to the docs:

Spot Instance Requests support all the same arguments as aws_instance

and most of these args (security_groups, etc.) except tags seemed to be passed thru to the created instance by AWS itself.

@johnnyshields
Copy link
Author

One more comment, to meet the immediate need I'd be in favor of merging PR #4380 even if a different option is chosen in the future (they aren't mutually exclusive.)

@johnnyshields johnnyshields changed the title How to Handle AWS Spot Instances (tags, etc.) How to Handle AWS Spot Instance args (tags, etc.) May 20, 2016
@cbarbour
Copy link

This is the documented behavior of AWS spot instances, rather than a bug in the AWS provider.

As a workaround, consider using an auto-scaling group. The autoscaling group can request spot instances, and the launch_configuration will pass tags onto the instance. You don't need to autoscale the autoscaling group; you can specify the pool size manually.

The downside to that approach, is that the autoscaling resources do not provide attributes for the resulting instances.

@ghost
Copy link

ghost commented Apr 10, 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 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.

@ghost ghost locked and limited conversation to collaborators Apr 10, 2020
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

4 participants