-
Notifications
You must be signed in to change notification settings - Fork 97
populate admin_features_package and product_types in ec_security_project ReadI() #939
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
base: master
Are you sure you want to change the base?
populate admin_features_package and product_types in ec_security_project ReadI() #939
Conversation
…_project Read()
The Read() function in ec_security_project was not populating the
admin_features_package and product_types fields from the API response,
causing them to remain in an 'unknown' state after resource creation.
This resulted in Terraform errors: 'Provider returned invalid result
object after apply'.
This fix adds the missing field population logic in the Read() function:
- admin_features_package uses NewStringPointerValue() pattern (matching
observability_project pattern for optional pointer fields)
- product_types is converted from API response format to Terraform list
Updated tests to verify the fields are correctly populated.
Fixes elastic#938
Assisted by Cursor AI.
37300d1 to
9644ee7
Compare
… doesn't return them
9644ee7 to
a957266
Compare
| resource ec_security_project "%s" { | ||
| name = "%s" | ||
| region_id = "%s" | ||
| admin_features_package = "standard" |
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.
We need to have at least one acceptance test which verifies that these values can be set, and updated successfully by the provider.
| type securityModelReader struct{} | ||
|
|
||
| // productTypesOrderInsensitivePlanModifier ignores order differences in product_types list | ||
| type productTypesOrderInsensitivePlanModifier struct{} |
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.
Based on the comment here, I think we actually want to create a custom type for the product types. That type can then implement ListValuableWithSemanticEquals which:
- Applies the same logic as this plan modifier during the planning phase
- Critically, applies the same logic during the post application checks which will avoid the inconsistent state error I imagine we'd get if the TF config defined product types in a different order to what was returned by the API.
| productTypeValues := []attr.Value{} | ||
|
|
||
| if len(sourceProductTypes) > 0 { | ||
| // Use the ordering from state/config, but with values from API |
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.
See the custom type comment above. We can bundle all this logic i.e the plan modifier and this ordering shenanigans into the custom type.
The Read() function in ec_security_project was not populating the
admin_features_package and product_types fields from the API response,
causing them to remain in an 'unknown' state after resource creation.
This resulted in Terraform errors: 'Provider returned invalid result
object after apply'.
This fix adds the missing field population logic in the Read() function:
Updated tests to verify the fields are correctly populated.
Fixes #938
Assisted by Cursor AI.