can not import redshift_users that is a superuser with self-managed password

[mtesch-um]

For users who do not want to manage their passwords via the terraform module, but DO want to manage super users, the check I (dumbly) requested for super user passwords prevents that -- superusers only need to have their password set at the time that they are created on redshift, not when they are imported.

Currently I get the following when trying to upgrade from 0.5.0 to 0.6.0:

│ Error: Users that are superusers must define a password.
│ 
│   with module.main.redshift_user.users["foo_super"],
│   on ../modules/redshift/main.tf line 40, in resource "redshift_user" "users":
│  40: resource "redshift_user" "users" {
│ 
│ Error: Users that are superusers must define a password.
│ 
│   with module.main.redshift_user.users["bar_super"],
│   on ../modules/redshift/main.tf line 40, in resource "redshift_user" "users":
│  40: resource "redshift_user" "users" {
│ 

The check to make sure a super user resource has a password shoudl only occur if the user doesn't exist in redshift. Anyway, I think my original feature request was misguided and pointless, apologies!

[winglot]

I think you can workaround that and have superusers imported and managed by terraform while having their passwords managed externally.

When you do an import of redshift_user, it leaves the password attribute in the state set to null (since it cannot read password from Redshift) and this is why this error is triggered in the first place. What you can do is modify the state directly and set the password attribute to some dummy value, eg. SELF MANAGED and ignore changes on it. The resource for that would look like this:

resource "redshift_user" "superuser" {
  name      = "super_user"
  superuser = true

  password = "SELF MANAGED"
  lifecycle {
    ignore_changes = [password]
  }
}

Would that work for you?

[mtesch-um]

@winglot here's my suggestion: #70 - it will just delay the error until the apply (passing through the error from redshift on the attempt to create a super user with no password.)

regarding the workaround - I tried it and it still creates the error. Also, wouldn't that overwrite the password with the dummy value the next time anything non-ignored changed on the resource? (actually it works)