Deprecate artifactory_user and resource/artifactory_unmanaged_user in favor of resource/artifactory_managed_user

[danielmkn]

Both artifactory_user and resource/artifactory_unmanaged_user resources generate a user password if it wasn't set in the HCL. That approach was chosen to make bulk user creation easier.

The problem is we can't save this generated password in the state, because of SDKv2 limitations. Adding the password in the Create function creates a state drift, and using DefaultFunction generates the password twice, leading to the drift as well.
Another problem, even if we could store the generated password in the state, on the next update there will be a state drift unless it's ignored by the lifecycle.

We've decided to deprecate these two resources and get rid of generating passwords on the Artifactory Provider side.
For now, we recommend using artifactory_managed_user and generating passwords using a separate provider.
The PR is here, we will merge it if there is no comments within a week.

Any ideas and suggestions are welcome!

[danielmkn]

Hi @jcogilvie, @tjstansell, @ShreyasNBS, and @akashgupta-nbs! You've participated in the relevant discussion before. Can you please express your opinion?

[jcogilvie]

My primary requirement is that I need the ability for a user to have an account created, and then use the password reset flow to get access, and have that operation not be detected as drift or be undone by terraform.

I'll have to peruse our previous discussions to make sure any other cases I require are also covered but won't be able to do that until next week.

[tjstansell]

Well, I've never understood why there are 3 separate user resources. It seems you could have just as easily kept artifactory_user and simply added options to change behavior on how passwords were handled. My only gripe is that there's no easy migration path to switch from one resource type to another. We'll likely have to manually edit our state file to change it from resource_user to resource_managed_user. And if there's no longer going to be a resource_unmanaged_user, it sure seems like only having resource_managed_user feels mis-named. Whatever. We already set password to a random value in terraform and then just use

  lifecycle {
    ignore_changes = [password]
  }

to ignore any changes. I don't think changing types will cause us any grief other than the unnecessary renaming of the resources and the manual manipulation of the state file that's required.

[jcogilvie]

Rereading the old discussion thread, and your PR, it looks like you're proposing to make password mandatory again. For the same reasons as in the previous discussions, this is a non-starter for my use case. Please correct me if I'm wrong.

Once again, my use case is to force users through the password reset flow. I don't care what the password is when it's created, and my state (in your provider or another provider) should not care, either. And if we're talking about making a password somewhere else and passing it into the user for first-time creation only, then I'll have to make multiple passes on every user I create (to add the user with a password I don't care about, and another to forget the password).

The approach other providers take (e.g., amazon) is to decouple user creation from password creation (maybe by sending an email to a user to create a password?). Until the artifactory server supports that flow, I can neither endorse this change nor use the provider if it forces me to supply a password. I'll effectively be pinned to the present version for good.

[jcogilvie]

Yeah, on further consideration, I'm currently sitting on a pile of `artifactory_user`s and I really don't want to do that state surgery on all my developers. (Edit: replying by email, this should have been a reply to @tjstansell on the thread above.)

[alexhung]

You may be already familiar with this tool: hcledit

[jcogilvie]

That's great, but it's not the code I'm worried about. It's the state file migration, like @tjstansell mentioned.

If I just update the hcl to use the new resource, all my users get deleted and recreated, which means everyone needs to set up auth again.

And there's no straightforward way to edit my state file since my company doesn't allow access to our state files from dev environments. Everything I do has to be runnable without an interactive session as a one-off command in a github action.

[danielmkn]

Thanks for your comments, everyone! We really appreciate it.
I'm gonna update the documentation for the relevant resources, adding appropriate use cases for each of them. We won't deprecate the resource to avoid creating difficulties for you.

[jcogilvie]

Thank you for listening and taking the feedback in stride!