Docs: Undocumented backwards-incompatible change for artifactory_keypair

[skyzyx]

Describe the bug

Overnight, we upgraded our production Artifactory cluster from 7.49.10 → 7.71.3. This allowed us to upgrade from provider v6.37.0 → v10.1.2.

A review of "BREAKING CHANGES" in the CHANGELOG showed that we were not impacted by any documented backwards-compatible changes to the Provider.

However, after updating this block to v10…

required_providers {
  # https://github.com/jfrog/terraform-provider-artifactory/releases/latest
  artifactory = {
    source  = "registry.terraform.io/jfrog/artifactory"
    version = "~> 10.0"
  }
}

…running terragrunt init -reconfigure -upgrade, and then terraform plan, I received errors related to artifactory_keypair. (We use RSA keys for Alpine Linux repositories, and GPG keys for Amazon Linux, CentOS, and Ubuntu repositories.)

At some point, the computed id value was removed. My best guess at a replacement is pair_name.

Requirements for and issue

• A description of the bug
• A fully functioning terraform snippet that can be copy&pasted (no outside files or ENV vars unless that's part of the issue). If this is not supplied, this issue will likely be closed without any effort expended.
• Your version of artifactory (you can curl it at $host/artifactory/api/system/version
• Your version of terraform
• Your version of terraform provider

Terraform v1.7.1
on darwin_arm64
+ provider registry.terraform.io/jfrog/artifactory v10.1.2

Expected behavior

The documentation (CHANGELOG, Migration Guide?) should note this as a breaking change and when it happened.

Additional context

Aside from this, the upgrade across that many major versions of the provider was remarkably boring! Thank you!

[skyzyx]

OK, weird. I started with the docs for v10.1.2 for artifactory_keypair, then worked my way back through many old versions of the docs — binary search style — trying to find where the id property was removed.

Apparently, it's never been documented. 😕❓

But I was using it successfully in versions 3.x → 6.37.0. Maybe I just guessed that it existed, and the provider didn't push back on me?

[danielmkn]

Hi @skyzyx! @alexhung will be back next week and will take a look! Thanks for reporting.

[alexhung]

@skyzyx The artifactory_keypair resource was migrated from the SDKv2 library to the new Framework library in 9.7.0.

The id field was never part of the public schema but it's a requirement from the SDKv2 library. The new Framework has no such need so the id field is dropped by the provider.

See dde9a5e#diff-c44e81aa2aba4fad7737a7ad8b14afb04ab255fee0e58e2660737c6e76946c36L34

I'll investigate on what steps are needed for upgrading and add to documentation.

[skyzyx]

Ahhh. That makes sense.

Actually, am I mistaken in thinking that the Terraform Plugin Framework does require an id parameter? I know it's required for Data Sources (as I maintain a Provider that is Data Source only), but maybe it isn't for resources?

[alexhung]

@skyzyx No, the fact that SDKv2 treats id attribute with special meaning was one of the thing HashiCorp team fixed in Framework. Now there is no special attribute and it's up to the provider to figure out which attribute to use for identity. AFAIK, same applies to data source.

[alexhung]

@skyzyx Sorry it's been a while since I last touch this. Do you still have the error message from artifactory_keypair when you upgrade?

And how did you resolve the issue? 😄

[alexhung]

@skyzyx I installed provider 6.37.0 and created a new key pair resource on my local Artifactory instance. Then I upgraded provider to 10.1.4, ran terraform apply, and got no error.

In my state file, the id field still exists: