-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support reading existing objects that are not managed by tf #68
Comments
Which version of the provider are you using? By default in v2.0.0-alpha1 if you do not set a password on a user it will not manage the password or change it. I can confirm this is the behaviour as we have imported many users using this method. The docs I have written around this should also confirm this behaviour, although I'm happy to update if incorrect:
I also believe your import commands are incorrect for the example you listed. The correct syntax is: terraform import "artifactory_user.user[1]" unmanaged_user1
terraform import "artifactory_user.user[2]" unmanaged_user2 |
We're building the provider off master. A quick comparison to v2.0.0-alpha1 doesn't show any obvious user affecting differences that could explain why passwords are being reset.
Thanks for the correction, I've tested your suggestion and corrected my issue to reflect that it does work as expected to import, though would still be clunky to complete / repeat on a regular basis to resolve any manual creations. |
Community Note
Description
I'm currently managing an artifactory instance were some users are managed by TF, and some are not (I know... don't ask...).
Blindly adding users to TF causes their passwords to be reset as TF plan reports it will "add" (create) the users rather than modify, and TF apply just reports they've been created, presumably as it's not aware that it's inadvertently overwriting... which for a bulk import of all users to bring them into state would be very disruptive.
I've experimented with using
terraform Import
, but it's cumbersome and requires an external loop over all named resources as it doesn't seem to accommodate for importing the whole run.As a good work around, and useful extension to this provider, It would be useful if either the existing
artifactory_user
resource did some validation checks against artifactory (or had a flag to allow for this).Alternatively if there was a data source for each available resource (or at least
artifactory_user
) to allow for gathering of unmanaged state then that could be used as a base for migrating un-managed to a managed state.New or Affected Resource(s)
artifactory_user
data artifactory_*
Potential Terraform Configuration
The text was updated successfully, but these errors were encountered: