You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
If an issue is assigned to the "modular-magician" user, it is either in the process of being autogenerated, or is planned to be autogenerated soon. If an issue is assigned to a user, that user is claiming responsibility for the issue. If an issue is assigned to "hashibot", a community member has claimed the issue already.
Specifying the certificate_id in the config to avoid a diff in this case shouldn't be required - indeed it should arguably be an error to specify certificate_id when ssl_management_type = AUTOMATIC (and I expect if it I set the field, it would generate an API error).
The overall way that certs are exposed within the domain mapping resource doesn't really make sense to me. Logically, what makes sense is to have an optional certificate_id argument can be specified if and only if ssl_management_type = MANUAL (better UX would probably be to have an optional block like manual_ssl_settings entirely). For auto certs, it shouldn't really be necessary to think about the certificate ID at all, but if we need to expose it, we should provide computed attributes certificate_id and for pending_managed_certificate_id - they don't make sense as arguments.
The text was updated successfully, but these errors were encountered:
Not sure exactly what the resolution was but it seems to have been to leave them as inputs? (I am not that familiar with Terraform, maybe there's some distinction I'm missing.)
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. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!
ghost
locked and limited conversation to collaborators
Nov 25, 2019
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Community Note
Terraform Version
Affected Resource(s)
Terraform Configuration Files
The example snippet suffices:
Expected Behavior
Once this config is applied, it should continue to be valid, regardless of the status of the AUTOMATIC SSL cert renewal.
Actual Behavior
Once the SSL cert is provisioned,
terraform plan
starts showing a diff like this:Specifying the
certificate_id
in the config to avoid a diff in this case shouldn't be required - indeed it should arguably be an error to specifycertificate_id
whenssl_management_type = AUTOMATIC
(and I expect if it I set the field, it would generate an API error).The overall way that certs are exposed within the domain mapping resource doesn't really make sense to me. Logically, what makes sense is to have an optional
certificate_id
argument can be specified if and only ifssl_management_type = MANUAL
(better UX would probably be to have an optional block likemanual_ssl_settings
entirely). For auto certs, it shouldn't really be necessary to think about the certificate ID at all, but if we need to expose it, we should provide computed attributescertificate_id
and forpending_managed_certificate_id
- they don't make sense as arguments.The text was updated successfully, but these errors were encountered: