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
When schema resource is updated, terraform plan produces the following output:
~ resource "confluent_schema" "this" {
id = "***/example_topic_2_value/latest"
~ schema = jsonencode(
~ {
~ fields = [
# (3 unchanged elements hidden)
{
default = "12345678"
name = "phoneNr"
type = "string"
},
+ {
+ default = "default"
+ name = "occupation"
+ type = "string"
},
]
name = "ExampleMessage1"
# (1 unchanged attribute hidden)
}
)
# (6 unchanged attributes hidden)
}
Among the "# (6 unchanged attributes hidden)" there is the schema_identifier attribute, which does change in the apply step. This leads to some undesired behaviour in our ADO pipeline setup:
updating tag_binding resource to point to the newer schema version requires an additional pipeline run to trigger the change to the tag_binding resource
adding a new tag_binding to the newly evolved schema is not possible in a single plan&apply step, instead the following error is produced:
│ Error: Provider produced inconsistent final plan
│
│ When expanding the plan for
│ module.kafka-resources.confluent_tag_binding.tag_binding["test_pipeline:pilot_application-example:pet"]
│ to include new values learned so far during apply, provider
│ "registry.terraform.io/confluentinc/confluent" produced an invalid new
│ value for .entity_name: inconsistent values for sensitive attribute.
│
│ This is a bug in the provider, which should be reported in the provider's
│ own issue tracker.
For now the easy, but more time consuming and not desirable in the long-run workaround, is to run the pipeline twice or separate the logic of managing schemas and tag binding resources in separate pipeline stages.
It would be great if a change to confluent_schema resource could show the planned change to the schema_identifier attribute in the plan step (preferably indicating with (known after apply) ) to correctly reflect the changes to resources depending on that attribute.
The text was updated successfully, but these errors were encountered:
We definitely agree that it would be great to fix this issue! The challenge is that it seems like it's a terraform issue where it uses the existing values of computed attributes during terraform plan. However, in this case, we would need to use the updated value of the computed attribute when creating a tag binding in a single terraform plan && terraform apply.
When schema resource is updated, terraform plan produces the following output:
Among the "# (6 unchanged attributes hidden)" there is the schema_identifier attribute, which does change in the apply step. This leads to some undesired behaviour in our ADO pipeline setup:
For now the easy, but more time consuming and not desirable in the long-run workaround, is to run the pipeline twice or separate the logic of managing schemas and tag binding resources in separate pipeline stages.
It would be great if a change to confluent_schema resource could show the planned change to the schema_identifier attribute in the plan step (preferably indicating with (known after apply) ) to correctly reflect the changes to resources depending on that attribute.
The text was updated successfully, but these errors were encountered: