terraform plan extermely slow with provider version greater then 7.11.2

[jcoste-orange]

We have a pretty big terraform infrastructure for Artifactory :

• 2095 remote repositories
• 2095 virtual repositories
• 2095 permission targets
• 2095 users

Everything was working great with version 7.11.2 of the provider.
1m30s to perform a plan for example.

But after an upgrade to 8.3.1, the plan operation takes 33 minutes !!

Artifactory Version :7.59.11
Terrform version : 1.5.5
Provider version : 8.3.1

I can't but the files (it's huge and as there is project names in it, I can expose them).

When I am in INFO level I have those warning (already have those in v7.11.2)

2023-09-19T12:02:47.161Z [WARN]  Provider "registry.terraform.io/jfrog/artifactory" produced an invalid plan for artifactory_virtual_docker_repository.<redacted>-virt-docker-unstable, but we are tolerating it because it is using the legacy plugin SDK.
4411    The following problems may be the cause of any confusing errors from downstream operations:
4412      - .project_key: planned value cty.StringVal("default") for a non-computed attribute
4413      - .resolve_docker_tags_by_timestamp: planned value cty.False for a non-computed attribute
4414      - .artifactory_requests_can_retrieve_remote_artifacts: planned value cty.False for a non-computed attribute
4415      - .includes_pattern: planned value cty.StringVal("**/*") for a non-computed attribute
4416      - .default_deployment_repo: planned value cty.StringVal("") for a non-computed attribute
4417      - .description: planned value cty.StringVal("") for a non-computed attribute
4418      - .excludes_pattern: planned value cty.StringVal("") for a non-computed attribute
4419      - .repo_layout_ref: planned value cty.StringVal("simple-default") for a non-computed attribute

Can this degrade performance ?

[jcoste-orange]

I was able to locally test this terraform config on a newly install artifactory.
The regression was introduced by v8.1.0 of the provider. With this version terraform is consumming all my CPU cores (16) for very long time (I stop afeter 10 mins)

[alexhung]

@jcoste-orange this is caused by the terraform-plugin-framework package. See #757

[jcoste-orange]

I still have huge cpu consumption with the latest versions of the provider, even v9.0.0.

[alexhung]

@jcoste-orange The performance hit is mostly in the artifactory_permission_target resource. I've been in contact with HashiCorp team but so far no definitely answer.

[testworksau]

We are experiencing the same issue.

[alexhung]

@jcoste-orange @testworksau I'd encourage you to also voice your experience in this HashiCorp community thread: https://discuss.hashicorp.com/t/performance-issue-with-terraform-plugin-framework/58422 Hopefully TF team will see it and prioritize the fix.

[anstrom]

Has there been any progress on this?

We are stuck with v7 because of the performance problems with artifactory_permission_target. Our pipeline in GitLab works great in v7, but is unable to complete a terraform plan with v8 and newer.

Is there any chance you could revert to the legacy SDK for artifactory_permission_target until the underlying problem is fixed, or is there a workaround we can use?

[alexhung]

@anstrom

Is there any chance you could revert to the legacy SDK for artifactory_permission_target until the underlying problem is fixed

This has been in my mind for some time now. Initially I was hoping HashiCorp would resolve this issue relatively quickly but this doesn't seem to be the case. So we'll consider reverting back to SDKv2 version since this is the worst offender.

[anstrom]

🎉

[alexhung]

@anstrom @jcoste-orange @testworksau Let me know how well this work out for you. Hopefully terraform plan should be back to previous performance level.

[jrarmstro]

Terraform plan seems to be performant again with the latest versions on my end.