Open tllano11 opened 8 months ago
@tllano11 Thanks for opening this, could you please reduce the plan into something smaller and easy to reproduce to make things go faster, thanks!
Thanks for the quick reply @cderici . I just updated the terraform plan in the bug description and included some debug output as well. I tried to reduce the plan as much as I could. Let me know if there is anything else you need me to add or modify.
This issue does not appear to be a duplicate of #182. In this case, there are 3 placement values, but only 1 value is put back in after deploy.
I also noticed that sometimes no value is put back at all. In the Debug/Panic Output section of the issue description, the last error shows this.
Adding to this, also getting this error. Any idea when a fix might be released to the provider?
Terraform - https://github.com/canonical/kafka-bundle/tree/main/terraform/dev Command that deploys it - https://github.com/canonical/kafka-bundle/blob/38ab7c3d5df4465c3c4ff4b71994ab709aa11962/tests/integration/terraform/test_terraform.py#L30-L64 Failing messages - https://pastebin.com/1kUgVSv8
I can reproduce this same issue without using "placement", e.g.:
Using Juju provider: v0.10.1 Terraform: v1.7.4
resource "juju_application" "opensearch" {
name = "opensearch"
model = var.model_name
charm {
name = "opensearch"
channel = var.opensearch_channel
base = var.opensearch_base
}
constraints = join(" ", [
for k,v in {
"instance-type" = var.opensearch_constraints.instance_type
"root-disk" = var.opensearch_constraints.root-disk
"spaces" = var.opensearch_constraints.spaces
} : "${k}=${v}"
])
units = var.opensearch_count
}
Results in:
│ Error: Provider produced inconsistent result after apply
│
│ When applying changes to module.opensearch.juju_application.opensearch, provider "provider[\"registry.terraform.io/juju/juju\"].aws-juju" produced an
│ unexpected new value: .constraints: was cty.StringVal("instance-type=c6a.xlarge root-disk=100G spaces=internal-space"), but now cty.StringVal("arch=amd64
│ instance-type=c6a.xlarge root-disk=102400M spaces=internal-space").
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
An update has been added to 0.11.0 for placements. All machines should be written when deploying. There is still a problem with order to fix. I have some work in progress here.
Unfortunately this issue persists in version 0.13.0
juju_application.test: Creating...
╷
│ Error: Provider produced inconsistent result after apply
│
│ When applying changes to juju_application.test, provider "provider[\"registry.terraform.io/juju/juju\"]" produced an unexpected new value: .placement: was cty.StringVal("1,2"), but now
│ cty.StringVal("1").
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
╵
Description
When applying changes to juju_application.ceph_mon for a Ceph deployment using Terraform, the provider "provider["registry.terraform.io/juju/juju"]" produced an unexpected new value in the .placement attribute. Specifically, it was cty.StringVal("1,0,2"), but after the apply, it changed to cty.StringVal("0"):
The particular use case here is deploying ceph on virsh VMs managed through MAAS and juju. First, MAAS is configured manually in the VM host, then a MAAS cloud is configured in juju using a virsh VM as the controller. Afterwards, terraform is used to:
This problem occurs in step 4, when coordinating the deployment of
ceph-mon
units on the same machines asceph-osd
units. the pattern is:Urgency
Casually reporting
Terraform Juju Provider version
0.10.0
Terraform version
v1.6.6
Terraform Configuration(s)
Reproduce / Test
terraform init && terraform apply
Debug/Panic Output
Notes & References
The OSDs and Monitors are depoyed successfully, but the integration is skipped due to errors reported by the juju_application resource. The output of
juju switch ceph && juju status
is as follows: