feat: allow custom domains to be associated with a deployment #19
Conversation
magurotuna
changed the title
| # See the doc of deno_domain resource for the full example of the entire process of domain setup. | ||
|
|
||
| # `depends_on` may be useful to ensure the domain is ready. | ||
| depends_on = [deno_certificate_provisioning.example] |
There was a problem hiding this comment.
If we don't do this, does it still work? I would suspect that the lack of verification for the domain would make it not work.
There was a problem hiding this comment.
The deployment <-> custom domain association API checks if the requested domain is owned by the requester; therefore, at least depends_on = [deno_domain_verification.example_domain_verification] is needed to get successful association. However, waiting on deno_certificate_provisioning is not a requirement for the association to succeed.
Here I put depends_on = [deno_certificate_provisioning.example] because deno_certificate_provisioning in turn depends on deno_domain_verification, so we don't need to explicitly specify the grandchild dependency. But this is a documentation, so I'm wondering what information should be mentioned here
|
Another question, any reason this is on the deployment resource rather than on the domain resource? |
Because letting 
Whereas with the current structure that I have adopted, the dependency graph looks like the below (note there's no circular dependency): 
|
This commit adds a new attribute
domain_idstodeno_deploymentresource.This attribute is optional. So only when it's present, the resource will make an API call to associate the domain(s) with the deployment.
Also, when a resource is deleted, it will disassociate the domain(s) from the deployment, although the deployment itself will remain untouched since it's immutable.
Closes #12
Initially I thought I would create a new resource like
deno_domain_deployment_associationthat manages the association between domain and deployment, but decided not to do that, because this interface might bring a misunderstanding that we can do N to N mapping between deployments and domains; in fact one deployment can have multiple custom domains, but the opposite is not allowed.To avoid this confusion,
deno_deploymentresource can take a list of domain IDs, which clearly reflects the fact that one deployment can have multiple custom domains.One thing that may be concerning is that the domain doesn't get disassociated from the deployment in the scenario like:
deno_deploymentresource, with a custom domain applied (1stterraform applyhere)domain_idsattribute in the config file (2ndterraform applyhere)In order to address this issue we probably would like to get "get_deployment" API to return the domain IDs associated with the deployment, so that we can figure out what domains are deleted from the config.