-
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
r/spot_fleet_request - add import support #12767
r/spot_fleet_request - add import support #12767
Conversation
placing this under wip as rebase probably won't be clean after #12732 |
thanks for the heads-up @DrFaust92 :) |
@anGie44 , removing WIP. I think the other PR is mostly done and stabilized |
Code changes LGTM @DrFaust92! I'm just seeing test failures on my end w/re to on-destroy but still investigating as your changes here are unrelated |
ResourceName: resourceName, | ||
ImportState: true, | ||
ImportStateVerify: true, | ||
ImportStateVerifyIgnore: []string{"wait_for_fulfillment"}, |
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.
@DrFaust92 this test is an interesting one b/c a diversified
allocation_strategy cannot be set with an instance_pools_to_use_count
; the SDK returns InstancePoolsToUseCount option is only available with the lowestPrice allocation strategy
if a user for example provides a value greater than 1 via the resource schema. in this case however, we avoid the error by using the default which results in not setting the spotFleetConfig.InstancePoolsToUseCount
with this value, but the imported state has a nil value for instance_pools_to_use_count
, explaining the test error
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.
perhaps a schema change is in order to address the fact that the default value of instance_pools_to_use_count
is technically not valid for cases where allocation_strategy
is not lowest-price
@bflad?
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.
..though to avoid too much change and since the field is set with the ForceNew
attribute, a possible work around could be to explicitly set instance_pools_to_use_count
w/in resourceAwsSpotFleetRequestRead
(for cases where the config object returns nil i.e. where allocation_strategy
!= lowest-price
) to match the default expected value of 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.
There are a few options in this scenario:
- Add
instance_pools_to_use_count
to theImportStateVerifyIgnore
- Add
d.Set("instance_pools_to_use_count", 1)
in the import state function - Adjust the schema for
instance_pools_to_use_count
fromDefault: 1
toComputed: true
to denote its multiple defaults (this however will require additional adjustments in theCreate
logic to check the allocation strategy in addition to the!= 1
)
The first option would just make the tests pass for the sake of passing (still representing an operator user experience problem after import). The second option would technically be a no-op change to the resource, since that would match the implicit Create
behavior where the attribute Default
is passed through to the state because d.Set()
in Read
is not overwriting the value. The third option would technically be the most correct given the API descriptions, however it would prevent that attribute from always being set as it is today, which represents a slight breaking change if any configurations are dependent on that behavior in attribute references.
I think I lean towards option two as the safest choice to implement import to match the existing behavior and a separate followup issue can be added to track fixing the attribute schema and its handling in Create
, potentially saved for a future major version (unless its actually causing issues of course!).
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.
ill address this with the second option as proposed
ResourceName: resourceName, | ||
ImportState: true, | ||
ImportStateVerify: true, | ||
ImportStateVerifyIgnore: []string{"wait_for_fulfillment"}, |
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.
There are a few options in this scenario:
- Add
instance_pools_to_use_count
to theImportStateVerifyIgnore
- Add
d.Set("instance_pools_to_use_count", 1)
in the import state function - Adjust the schema for
instance_pools_to_use_count
fromDefault: 1
toComputed: true
to denote its multiple defaults (this however will require additional adjustments in theCreate
logic to check the allocation strategy in addition to the!= 1
)
The first option would just make the tests pass for the sake of passing (still representing an operator user experience problem after import). The second option would technically be a no-op change to the resource, since that would match the implicit Create
behavior where the attribute Default
is passed through to the state because d.Set()
in Read
is not overwriting the value. The third option would technically be the most correct given the API descriptions, however it would prevent that attribute from always being set as it is today, which represents a slight breaking change if any configurations are dependent on that behavior in attribute references.
I think I lean towards option two as the safest choice to implement import to match the existing behavior and a separate followup issue can be added to track fixing the attribute schema and its handling in Create
, potentially saved for a future major version (unless its actually causing issues of course!).
Co-Authored-By: angie pinilla <[email protected]>
23a569c
to
0f33994
Compare
Co-Authored-By: Brian Flad <[email protected]>
Co-Authored-By: Brian Flad <[email protected]>
rebased + minor change for import
|
Confirmed output of acceptance tests in teamcity:
|
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.
LGTM (acceptance tests pass minus #13065 failures) 👍
This has been released in version 2.60.0 of the Terraform AWS provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading. For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template for triage. Thanks! |
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! |
Community Note
Release note for CHANGELOG:
Output from acceptance testing: