Octopus Space resources defined with space_managers_teams are not idempotent

[pstephenson02]

Describe the bug
Octopus Server mutates the state of new Octopus Spaces by adding a new Space Managers team to the space (with an id: teams-spacemanagers-Spaces-Id). This team shows up in subsequent runs of terraform plan and/or apply, triggers an update in place, and Octopus complains when terraform tries to remove the team from the space.

Steps to reproduce

terraform {
  required_providers {
    octopusdeploy = {
      source  = "OctopusDeployLabs/octopusdeploy"
      version = "0.7.5"
    }
  }
}

provider "octopusdeploy" {
  address = "https://octopus.local"
  api_key = var.api_key
}

resource "octopusdeploy_space" "target_s3" {
  name                  = "Target - S3"
  space_managers_teams  = ["teams-managers"]
}

First run works fine...

❯❯ phils :: samples-terraform git(master) ✗ 13:55  terraform apply -var-file="secret.tfvars"
octopusdeploy_space.target_s3: Refreshing state... [id=Spaces-128]

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # octopusdeploy_space.target_s3 will be created
  + resource "octopusdeploy_space" "target_s3" {
      + id                          = (known after apply)
      + name                        = "Target - S3"
      + space_managers_team_members = (known after apply)
      + space_managers_teams        = [
          + "teams-managers",
        ]
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

octopusdeploy_space.target_s3: Creating...
octopusdeploy_space.target_s3: Creation complete after 0s [id=Spaces-130]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

But on any run after the first...

❯❯ phils :: samples-terraform git(master) ✗ 13:56  terraform apply -var-file="secret.tfvars"
octopusdeploy_space.target_s3: Refreshing state... [id=Spaces-130]

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # octopusdeploy_space.target_s3 will be updated in-place
  ~ resource "octopusdeploy_space" "target_s3" {
        id                          = "Spaces-130"
        name                        = "Target - S3"
      ~ space_managers_teams        = [
          - "teams-spacemanagers-Spaces-130",
            "teams-managers",
        ]
        # (3 unchanged attributes hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

octopusdeploy_space.target_s3: Modifying... [id=Spaces-130]

Error: octopus deploy api returned an error on endpoint /api/spaces/Spaces-130 - [Space Managers team can't be removed from the list of space managers.]

Expected behavior
Obviously this isn't a problem caused by the provider, but I would expect that the provider ignores this new team when comparing resource schema.

Logs and other supporting information
Terraform's documentation suggests using the provider SDK's built in schema function DiffSuppressFunc to ignore the state change. This sounded promising initially until I discovered this issue saying DiffSuppressFunc doesn't work for list-type attributes.

Screenshots
N/A

Environment and versions:

• OS: Windows 10
• Octopus Server Version: 2020.5.5
• Terraform Version: v0.14.5
• Octopus Terraform Provider Version: v0.7.5

[pstephenson02]

Discussed this issue offline. It only appears to be an issue if you pre-define the space_managers_teams attribute in the space resource. If you forgo the space_managers_teams attribute and only use the space_managers_team_members attribute, it works as you'd expect.

[jbristowe]

I believe this falls outside the scope of the provider. Therefore, I am closing this issue.

The state of the space is persisted as expected -- space_managers_teams contains two (2) entries. Unfortunately, your configuration doesn't reflect this. Therefore, Terraform will always see a difference between the state and the configuration. To resolve this, review your state file with terraform state pull and update your configuration to reflect what is persisted to state.

[ajaychoudhary-bcg]

We are also facing this issue. This is adding an additional manual step in our automation to add team once space is created, We want to provide team name while creating space. Is it possible to fix it as it falls under provider space, it would be great if we can avoid auto-creating the space manager team or storing that in the state.