terraform-provider-googleworkspace icon indicating copy to clipboard operation
terraform-provider-googleworkspace copied to clipboard

diffs on is_archived in group-settings on every run

Open jazzlyn opened this issue 2 years ago • 13 comments

Hi there,

to be honest, not related to this actual bug but in general, it's sad that this provider doesn't get maintained anymore. The old gsuite provider from deviavir got archived the second the hashicorp provider was released.

Terraform Version

Terraform v1.3.7 on linux_amd64

  • provider registry.terraform.io/hashicorp/google v4.46.0
  • provider registry.terraform.io/hashicorp/googleworkspace v0.7.0
  • provider registry.terraform.io/hashicorp/http v3.2.1
  • provider registry.terraform.io/hashicorp/local v2.2.3
  • provider registry.terraform.io/hashicorp/random v3.4.3

Affected Resource(s)

  • googleworkspace_group_settings

Terraform Configuration Files

resource "googleworkspace_group_settings" "test" {
  email = var.group.email

  # workaround for https=//github.com/hashicorp/terraform-provider-googleworkspace/issues/331
  # TODO: remove when solved
  # -----------------------------------------------------------------------------------------
  lifecycle {
    ignore_changes = [
      email,
    ]
  }
  # -----------------------------------------------------------------------------------------

  allow_external_members         = true
  allow_web_posting              = false
  archive_only                   = false
  enable_collaborative_inbox     = false
  include_in_global_address_list = true
  is_archived                    = false
  members_can_post_as_the_group  = false
  message_moderation_level       = "MODERATE_NONE"
  reply_to                       = "REPLY_TO_IGNORE"
  spam_moderation_level          = "ALLOW"
  who_can_assist_content         = "NONE"
  who_can_contact_owner          = "ALL_MANAGERS_CAN_CONTACT"
  who_can_discover_group         = "ALL_IN_DOMAIN_CAN_DISCOVER"
  who_can_join                   = "INVITED_CAN_JOIN"
  who_can_leave_group            = "NONE_CAN_LEAVE"
  who_can_moderate_content       = "OWNERS_AND_MANAGERS"
  who_can_moderate_members       = "OWNERS_AND_MANAGERS"
  who_can_post_message           = "ANYONE_CAN_POST"
  who_can_view_group             = "ALL_MEMBERS_CAN_VIEW"
  who_can_view_membership        = "ALL_IN_DOMAIN_CAN_VIEW"
}

Debug Output

  # module.gworkspace.module.group_settings["test"].googleworkspace_group_settings.group_settings will be updated in-place
  ~ resource "googleworkspace_group_settings" "group_settings" {
        id                                             = "[email protected]"
      ~ is_archived                                    = true -> false
        name                                           = "[email protected]"
        # (24 unchanged attributes hidden)

        # (1 unchanged block hidden)
    }

Expected Behavior

No changes. Your infrastructure matches the configuration. Default to is_archived is false regarding to docs.

Actual Behavior

constantly changes on is_archived (with settings above true -> false, false -> true when changing the value in settings) on every terraform plan I get a different number of resources to be changed. On apply the resources get modified but actually no real change to them.

Steps to Reproduce

configure group settings and then try to change the is_archived value.

jazzlyn avatar Jan 10 '23 09:01 jazzlyn

We've just ran into this, this morning as well; I wonder if something has changed upstream. I can't see any functional difference so I'm going to try ignoring with tf lifecycle.

Update:

ignoring with lifecycle worked fine and is fine for our use case as we don't use these groups for posting messages.

resource "googleworkspace_group_settings" "group-settings" {
  .....

  lifecycle {
    ignore_changes = [
      # https://github.com/hashicorp/terraform-provider-googleworkspace/issues/398
      is_archived
    ]
  }
}

dwilliams782 avatar Jan 10 '23 11:01 dwilliams782

This is rather annoying, although it seems like it's caused by a sneaky API change.. I got paranoid about people archiving groups 😓

SamuZad avatar Jan 10 '23 13:01 SamuZad

We have also encountered this today. The difference is that we actually DO set archive_only to true and the provider wants to change it to false. The API returns true BTW and it is correctly set.

hanneshayashi avatar Jan 11 '23 15:01 hanneshayashi

Same here. We have a mix of archived and non-archived groups, so it gets super confusing and we need to double-check each time that we don't accidentally turn off the archive where it's needed.

kpocius avatar Jan 12 '23 10:01 kpocius

same thing here! My plan suddenly showed 500 changes when onboarding someone! Luckely I can just lifecycle ignore this setting because we don't use archived groups.

gemonevictor avatar Jan 12 '23 12:01 gemonevictor

Can you run the plan with TF_LOG=trace terraform plan and show the output from the API? I checked the logic and it does look correct...

rosmo avatar Jan 12 '23 14:01 rosmo

This is curious. API does indeed return "isArchived": "true", for the affected groups, but it's definitely off in the UI

image

kpocius avatar Jan 13 '23 16:01 kpocius

Sounds to me like it's an API issue, and not an issue with the provider. If you have a support contract, I would file a request with them.

rosmo avatar Jan 13 '23 17:01 rosmo

It does indeed sound like an API issue. Especially since it's rather inconsistent. I'll reach out to Google, cheers.

kpocius avatar Jan 13 '23 18:01 kpocius

Same here, we're affected too.

paolomainardi avatar Jan 25 '23 16:01 paolomainardi

Google Workspace support told me to contact GCP support because we use SA to authenticate the provider (weird, but OK). Still haven't heard back from GCP support though.

kpocius avatar Jan 25 '23 16:01 kpocius

Thanks a lot, @kpocius, we are using workload identity federation from Gitlab CI which terminates using a SA, keep up posted.

paolomainardi avatar Jan 25 '23 16:01 paolomainardi

The issue has been resolved by Google. Provider is now working as expected again.

kpocius avatar Apr 04 '23 14:04 kpocius