-
Notifications
You must be signed in to change notification settings - Fork 9.1k
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
Spotfleet Launch Template and On-Demand Capacity Support #4866
Conversation
Looks like they calculated here and should not change if input config did not changed. |
EDIT: I went back and reevaluated and you're probably exactly right. I think I'm using the sets wrong. Let me make some changes and see if that works.
|
Ok, barring feedback and change requests this is now done with all spot fleet tests passing. @kkopachev I added a hashing function for the launch template set but tbh I'm still a little fuzzy on whether it was necessary. |
@lossanarch Could you rebase to resolve conflicts? |
Sorry @kkopachev, for some reason I thought it had to be done by someone with write access. Please excuse my inexperience. |
Is this going to be included in the upcoming 1.29.0? Thanks. |
Is there anything else I need to address with this one? |
Any word on when this might be merged? |
Can we get this in the next release please? |
@lossanarch Hey thanks for the work here! could you rebase this branch? Will have a look at it as soon as it's resolved :) Thanks! |
@lossanarch Definitely a big fan of this getting merged! |
@Ninir do you have any plan to review and merge this PR? |
Really looking forward to this one being merged soon. |
Why the silence? Should the PR be assigned to another reviewer? |
Sorry folks, I've been relocating from one country another and I need to get back in shape to contributing here. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @lossanarch
I made a more in-depth review before going for the final one. Thank you so much for the contribution and very very sorry for the latency here!
It is definitely a good work that will benefit a lot of people :)
|
||
### Overrides | ||
|
||
* `instance_type` - (Optional) The type of instance to request. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add an example about this one? If I may, would it be possible to make that example TF 0.12 compliant so that people understand how to do it?
This way, we would have a instance_type example with 0.12, and a subnet_id example with 0.11!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This sounds like a good idea but so far I've not been able to use 0.12 as not all providers I'm using are compatible. I'll need to get acquainted with it before I can do this.
* `weighted_capacity` - (Optional) The capacity added to the fleet by a fulfilled request. | ||
* `subnet_id` - (Optional) The subnet in which to launch the requested instance. | ||
|
||
**Note:** Instead of statically defining these override blocks they can be passed in as a list of maps containing the above keys and their values. This allows dynamic, programmatic generation of overrides based on variable or environment data. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thus would need to be reworded for TF 0.12 IMO, thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again same 0.12 problem as above. But particularly for this one, I wrote all of this specifically for the feature of dynamic, programmatic generation of overrides based on variable or environment data
which now feels defunct thanks to the new config syntax and particularly the foreach loops.
Optional: true, | ||
Computed: true, | ||
ForceNew: true, | ||
ConflictsWith: []string{"launch_template_configs.0.launch_template_specification.0.id"}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This ConflictsWith value will not work since launch_template_configs
is of TypeSet, and this syntax is allowed by TypeList only.
I'm thinking this should be handled in the CustomizeDiff instead, as it would allow to do it in a more efficient way.
@@ -360,6 +454,14 @@ func resourceAwsSpotFleetRequest() *schema.Resource { | |||
Set: schema.HashString, | |||
}, | |||
}, | |||
CustomizeDiff: customdiff.Sequence( | |||
customdiff.ComputedIf("launch_template_configs.0.launch_template_specification.0.id", func(diff *schema.ResourceDiff, meta interface{}) bool { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This wouldn't work since launch_template_configs
is of TypeSet and the syntax used here is for TypeList with MaxItems: 1
.
In this case, I would advise to iterate over the elements and check for the value using Go instead of HCL-based access. Let me know if that doesn't make sense!
@@ -360,6 +454,14 @@ func resourceAwsSpotFleetRequest() *schema.Resource { | |||
Set: schema.HashString, | |||
}, | |||
}, | |||
CustomizeDiff: customdiff.Sequence( | |||
customdiff.ComputedIf("launch_template_configs.0.launch_template_specification.0.id", func(diff *schema.ResourceDiff, meta interface{}) bool { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, since launch_template_specification
is Computed and Optional, this seems extraneous, since the differences would never show if not configured
return resource.RetryableError( | ||
fmt.Errorf("Error creating Spot fleet request, retrying: %s", err)) | ||
switch { | ||
case strings.Contains(awsErr.Message(), "LaunchTemplateSpecification"): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel we should be more specific about the message erroring, so that we can better handle different kind of errors.
We could rewrite part of this switch for something like:
if isAWSErr(err, "InvalidSpotFleetRequestConfig", "LaunchTemplateSpecification") {
return resource.RetryableError(err)
}
but instead of LaunchTemplateSpecification
, having a part of the sentence that matches a given error. Does that make sense?
resource.TestCheckResourceAttr( | ||
"aws_spot_fleet_request.foo", "launch_template_configs.#", "1"), | ||
resource.TestCheckResourceAttr( | ||
"aws_spot_fleet_request.foo", "launch_template_configs.4018047529.launch_template_specification.#", "1"), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note for me, I'm gonna check this one once running acceptance tests with TF_SCHEMA_PANIC_ON_ERROR=1 to be sure it's not a false positive
@lossanarch Any updates on this? Was trying to follow along where the progress of this issue is, but not sure since it haven't been updated in awhile. |
@lossanarch are you able to continue this PR? I think it's super valuable since it brings parity to spot fleet requests especially because AWS seems to be going down the path of supporting launch templates for all the other resources (EC2 Fleet, Auto Scaling). @bflad I noticed you had updated the milestones previously but somehow it got removed and GitHub made no mention of it. Anything you can do to assist shepherding this PR? I'm getting worried that this one has lost all of it's steam. |
Co-Authored-By: Gauthier Wallet <[email protected]>
Co-Authored-By: Gauthier Wallet <[email protected]>
Co-Authored-By: Gauthier Wallet <[email protected]>
What will it take to get this merged? We have the same need as many other commenters here. |
Is anyone still working on this feature? Is there anyone else that can take over? I would love to be able to manage our spot fleet launch templates through Terraform. |
I'm surprised this isn't getting more comments. This feature would be fantastic. |
Hi folks 👋 Please note that the commits in this pull request have been added into #12732 and that PR is now under review. Thanks to @lossanarch for working on this implementation. Please follow #12732 for further updates. 👍 |
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! |
Updates the spotfleet_request resource to support the new launch_template resource and on-demand capacity.
Changes proposed in this pull request:
The new block looks like this, following the structure from the go sdk as closely as possible:
Allows specifying a minimum portion of capcity to be filled by on-demand instances.
Any other tips & suggestions are appreciated.
Output from acceptance testing:
The above was the full set of spot fleet resource tests.
Of the above tests, these are the new ones: