v10.3.2 thinks existing `artifactory_user` resources do not exist and need to be created
Closed this issue · 5 comments
Describe the bug
When upgrading from provider version 10.3.1 to 10.3.2 a plan thinks all of our artifactory_user resources no longer exist and need to be created. Reverting back to 10.3.1 sees no changes are required. We've pinned to version 10.3.1 for now until we can figure out what the cause is. I haven't done much debugging yet, but wanted to report it to you here.
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:
7.33.12(yes it's old ... we're in the middle of migrating to a new cluster) - Your version of terraform
Terraform v1.7.5
on linux_arm64
+ provider registry.terraform.io/hashicorp/random v3.6.0
+ provider registry.terraform.io/jfrog/artifactory v10.3.2
- Your version of terraform provider
Expected behavior
It should continue to see the users exist and not want to recreate them.
Additional context
I'll start looking at debug output and see if I can see what's actually happening to help, but wanted to report this quickly to you.
Looks like the changes in 90ffb36 began using a different set of apis, namely https://jfrog.com/help/r/jfrog-rest-apis/get-user-list, which was introduced in artifactory version 10.49.3. This kind of change is a breaking change that should have involved a major version update as it changes the minimum version of artifactory it works against.
Given the use of the newer apis, we'll just pin the version until we finish our migration and get back onto a current version of artifactory. But you should update your docs and release notes noting the new minimum version requirement for artifactory.
Perhaps when you call the access/api/v2/users api, you can tell the difference between the api not existing (it returns a 404 in our case) versus there being an empty set of users and if the API doesn't exist you can fail fast and report the new minimum version requirement.
@tjstansell Thanks for the report!
This kind of change is a breaking change that should have involved a major version update as it changes the minimum version of artifactory it works against.
The change of API is not intended to have any functional or schema changes to the resource, thus it is not considered a breaking change.
This is definitely a bug on my part and I'll try to get a fix out tomorrow.
@tjstansell I think you're correct that either I add back the original API usage based on Artifactory version, or as you suggested fails if Artifactory version is below min version.
Right now I'm leaning on the former as it was not my intention to break backward compatibility.