#192 ⁃ Streaming Tenant Tokens still causes updates
Description
Activity

Unito io February 16, 2023 at 2:46 PM
➤ Erik Merkle commented:
> emerkle826 Don't have time to test it right now, but could this work?
>
> https://developer.hashicorp.com/terraform/language/meta-arguments/lifecycle#ignore_changes
Apparently the lifecycle block is only valid for resources, not datasources, so that approach won't work.
> For how long are the tokens valid?
The ones created via this plugin are set to never expire. So they are valid until the token or the tenant is deleted.

Unito io February 16, 2023 at 9:57 AM
➤ Oscar Bolmsten commented:
emerkle826 Don't have time to test it right now, but could this work?
https://developer.hashicorp.com/terraform/language/meta-arguments/lifecycle#ignore_changes
data "astra_streaming_tenant_tokens" "main" {
tenant_name = astra_streaming_tenant.main.tenant_name
cluster_name = astra_streaming_tenant.main.cluster_name
lifecycle {
ignore_changes = [
tokens
]
}
}For how long are the tokens valid?

Unito io February 15, 2023 at 6:42 PM
➤ Erik Merkle commented:
@oscar-b I have tried a bunch of tricks, but there doesn't seem to be a way around this. The only way for the provider to fetch the JWT token is to make the DevOps API call to read the token by ID. Doing this regenerates a new token each time. This is apparently by design, so it's not a bug. It does not invalidate previously fetched tokens, so if you are storing them off, they are still valid (for as long as they were valid to begin with).
The problem here is that I have to mark the field as Computed, which means it's never present in the ResourceData that Terraform sends to the Read on a terraform apply. The Read happens to make sure nothing has changed since the state was last written. So every time you do an apply that triggers a read of the Token, it's going to make a DevOps API call to fetch the token, which changes the token. I've tried a variety of ways to pull a token from the state prior to doing the DevOps API GET call, but there is just no way to do it outside of using terraform_remote_state and essentially separating the token data source from the rest of your terraform modules.
For example, you could have a main module and a tokens module like this:
./main.tf
./tokens/tokens.tfIn main.tf, you could define the DB and other things you want to manage.
But in ./tokens/tokens.tf, you would define your streaming tenant and your tokens:
terraform {
required_providers {
astra = {
source = "datastax/astra"
version = "2.1.12"
}
}
}
resource "astra_streaming_tenant" "tenant" {
tenant_name = "eriktenant"
topic = "topic1"
region = "us-east4"
cloud_provider = "gcp"
user_email = "erik.merkle@datastax.com"
}
data "astra_streaming_tenant_tokens" "tokens" {
tenant_name = astra_streaming_tenant.tenant.tenant_name
cluster_name = astra_streaming_tenant.tenant.cluster_name
}
output "jwt_token" {
value = data.astra_streaming_tenant_tokens.tokens.tokens[0].token
description = "The JWT token for the streaming tenant"
}Now, back in your main.tf, you could reference the state from that module as if it were remote state:
data terraform_remote_state "tokens" {
backend = "local"
config = {
path = "./tokens/terraform.tfstate"
}
}With this in main.tf, you can now access the token with references to
data.terrafomr_remote_state.tokens.outputs.jwt_tokenSince the token bits are now separated, running terraform apply on your main module would not trigger a read of the token, which will not update it since it is not managed by your main Terraform module.
The problem with this approach is that it's a hack and much more cumbersome to maintain. To use it, you have to initialize the token module separately and be aware of where it stores its state file. And you have to be able to isolate the details of the bits within it from the rest of your infrastructure such that the tokens module does not depend on anything in the rest of your modules. If you can arrange your configuration as such, you might be able to do it this way.
But essentially this only works if you separate your token Terraform management from anything that wants to reference it, and I would guess that's not easily done.

Unito io February 2, 2023 at 4:31 PM
➤ Erik Merkle commented:
@oscar-b Sorry I haven't been able to make any progress as of yet. It's on my list, I just have a few things that are consuming all of my time a the moment.

Unito io January 30, 2023 at 8:46 AM
➤ Oscar Bolmsten commented:
emerkle826 Any progress on this? Still causes issues here as it's being re-generated as a new value constantly.
This is a follow-up ticket for #188
Copying comments from the previous ticket:
https://github.com/datastax/terraform-provider-astra/issues/188#issuecomment-1328855545
https://github.com/datastax/terraform-provider-astra/issues/188#issuecomment-1328900703
https://github.com/datastax/terraform-provider-astra/issues/188#issuecomment-1328901554
using TF code:
data "astra_streaming_tenant_tokens" "main" { tenant_name = astra_streaming_tenant.main.tenant_name cluster_name = astra_streaming_tenant.main.cluster_name } resource "google_secret_manager_secret" "main" { secret_id = "astra-streaming-${var.project_id}-token" labels = local.labels replication { automatic = true } depends_on = [google_project_service.secretmanager-api] } resource "google_secret_manager_secret_iam_member" "main" { secret_id = google_secret_manager_secret.main.id role = "roles/secretmanager.secretAccessor" member = "serviceAccount:${var.service_account_email}" } resource "google_secret_manager_secret_version" "main" { secret = google_secret_manager_secret.main.id secret_data = data.astra_streaming_tenant_tokens.main.tokens[0].token }
┆Issue is synchronized with a Github issue by Unito
┆Issue Number: 192