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
The recently released Terraform 1.10 has added support for "Ephemeral Resources".
Such Ephemeral Resources are designed for resources such as secrets which the user dosen't want to store in the terraform state, but instead are provisioned ad-hoc during plan and apply phases.
Ephemeral resource support must be added to a provider; it is not something that simply becomes available for regular resources once upgraded to Terraform 1.10.
This feature request is for ephemeral resource support to be added to the following Grafana resources
grafana_cloud_stack_service_account_token
grafana_service_account_token
Concrete Use-case
It is hoped that this feature will be especially for the use case where a user has an appropriate Cloud Access Policy Token, and intends to configure a stack's resources which require a Service Account.
There is a somewhat-difficult-to-explain problem that can occur when you try to both provision a service account token, and then use that token to provision resources in a stack (alerts, dashboards etc) in a single Terraform, and if the token expires.
The initial plan / apply works fine: TF knows there are no resources in it's state, so can simply plan to create all of them.
So the first apply goes:
Create a service account with the Cloud Access Policy Token
Create a service account token with the Cloud Access Policy Token
Use the service account token in a Grafana provider alias
Use the Grafana provider alias to provision some resources
This works.
Later, we want to do anther plan / apply:
(we need to do "pre-apply plan" first, so TF knows what to apply)
Check we have the service account with the Cloud Access Policy Token
Check we have the service account Token with the Cloud Access Policy Token
Use the service account token stored in the TF state in the Grafana provider alias
Use the Grafana provider alias to check the required resources
Only after this "pre-apply plan" is done, can TF know what it needs to apply
This "pre-apply plan" requires the service account token stored in the TF state to be valid. This will not work if the token has expired.
We get into a chicken-and-egg situation here: We need a token to do the plan, but we won't have a valid token until we do an apply to refresh it, but we can't do an apply until we have done a plan to see if the local TF state matches the remote infra...
Workarounds
We can escape the above problem a few ways:
Provision the service account/token in another terraform; use the token as an output and then build the stack's resources in another terraform
Do a "partial apply" of the TF, only for the sepcific token resources. Do this before doing the "full apply" to ensure you have a valid token
How will this FR help?
As the token is generated ad-hoc in each phase, then the token should get generated at the beginning of the plan phase, before TF tries to check the remote infra which uses it
The text was updated successfully, but these errors were encountered:
Feature Request
The recently released Terraform 1.10 has added support for "Ephemeral Resources".
Such Ephemeral Resources are designed for resources such as secrets which the user dosen't want to store in the terraform state, but instead are provisioned ad-hoc during plan and apply phases.
Ephemeral resource support must be added to a provider; it is not something that simply becomes available for regular resources once upgraded to Terraform 1.10.
This feature request is for ephemeral resource support to be added to the following Grafana resources
Concrete Use-case
It is hoped that this feature will be especially for the use case where a user has an appropriate Cloud Access Policy Token, and intends to configure a stack's resources which require a Service Account.
There is a somewhat-difficult-to-explain problem that can occur when you try to both provision a service account token, and then use that token to provision resources in a stack (alerts, dashboards etc) in a single Terraform, and if the token expires.
The initial
plan
/apply
works fine: TF knows there are no resources in it's state, so can simply plan to create all of them.So the first
apply
goes:This works.
Later, we want to do anther
plan
/apply
:(we need to do "pre-apply plan" first, so TF knows what to apply)
Only after this "pre-apply plan" is done, can TF know what it needs to apply
This "pre-apply plan" requires the service account token stored in the TF state to be valid. This will not work if the token has expired.
We get into a chicken-and-egg situation here: We need a token to do the
plan
, but we won't have a valid token until we do anapply
to refresh it, but we can't do anapply
until we have done aplan
to see if the local TF state matches the remote infra...Workarounds
We can escape the above problem a few ways:
How will this FR help?
As the token is generated ad-hoc in each phase, then the token should get generated at the beginning of the
plan
phase, before TF tries to check the remote infra which uses itThe text was updated successfully, but these errors were encountered: