Error when using `cloudsmith_repository_privileges`

[jodoscott]

Terraform Version

Terraform v1.6.5
on linux_amd64

• provider registry.terraform.io/cloudsmith-io/cloudsmith v0.0.30

Affected Resource(s)

Please list the resources as a list, for example:

• cloudsmith_repository_privileges

Terraform Configuration Files

resource "cloudsmith_repository_privileges" "service_accounts" {
  for_each     = cloudsmith_repository.organization
  organization = var.cloudsmith_organization
  repository   = each.value.name

  service {
    privilege = "Write"
    slug      = cloudsmith_service.organization[each.value.name].slug
  }
}

Expected Behavior

The apply should have completed successfully.

Actual Behavior

Resources were created in cloudsmith, but apply produced an error.

Error: Provider produced inconsistent result after apply

When applying changes to
cloudsmith_repository_privileges.service_accounts["<service_account_name>"],
provider "provider[\"registry.terraform.io/cloudsmith-io/cloudsmith\"]"
produced an unexpected new value: Root object was present, but now absent.

This is a bug in the provider, which should be reported in the provider's own
issue tracker.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform apply

[BartoszBlizniak]

Hey @jodoscott - thank you for reporting this. I'm currently deploying a new update that should hopefully mitigate this issue, we have also noticed some inconsistency with the API itself which I have also created a ticket for internally to better handle the request.

[glowack2]

This still seems to be an issue in 0.0.33.

[BartoszBlizniak]

Hey @glowack2 / @jodoscott - I have release v0.0.34 - if you could provide some feedback on this version after the update that would be much appreciated.

Thank you,
Bartosz

[glowack2]

It doesn't seem to be fixed. I tried a new repo + privs and I got the same error. Privs did get created as confirmed by the UI, but it's not in the terraform state file. Also, I'm not sure if it's a related error or not, but when I reran the terraform plan again after the apply failed, it didn't detect that the repository even existed, and so the plan wanted to create the repo and privs again. I was also having trouble with a previous repo I created disappearing from the state file, and when I tried to re-import it, it couldn't find the repo. I'm thinking this is all pointing to an issue with reading the repo state from the system, seems like that might explain all these different symptoms?

[DanMcKinney]

Can confirm that I can replicate this. @BartoszBlizniak, I'll write up a ticket for this but happy to walk you through it when you get a moment.

[glowack2]

Following up here for posterity...

When you initially create a repo (using terraform or the API or UI), the user or service account that created the repo has Admin privs.

When cloudsmith_repository_privileges are created using Terraform, it overwrites what is already there, erasing the default Admin access. Thus, if you do not include your terraform user or service account as part of the privileges block, that account immediately loses access to the repo. This in turn leads to the repo effectively disappearing from view for Terraform, even though it still exists and is visible to the users who were granted access.

The solution is to include your Terraform user as an entry in your list of privileges in the Terraform code. If you are already locked out, you can add the user using the UI/API (with sufficient privs) to temporarily fix it until you can take control again through Terraform.

I decided this was reason enough to create a Terraform module for managing repos, privs, and upstreams together, and I hard-coded the service account we always use into the list so it will always have access and I can't accidentally lock myself out.

[jodoscott]

Following up here for posterity...

When you initially create a repo (using terraform or the API or UI), the user or service account that created the repo has Admin privs.

When cloudsmith_repository_privileges are created using Terraform, it overwrites what is already there, erasing the default Admin access. Thus, if you do not include your terraform user or service account as part of the privileges block, that account immediately loses access to the repo. This in turn leads to the repo effectively disappearing from view for Terraform, even though it still exists and is visible to the users who were granted access.

The solution is to include your Terraform user as an entry in your list of privileges in the Terraform code. If you are already locked out, you can add the user using the UI/API (with sufficient privs) to temporarily fix it until you can take control again through Terraform.

I decided this was reason enough to create a Terraform module for managing repos, privs, and upstreams together, and I hard-coded the service account we always use into the list so it will always have access and I can't accidentally lock myself out.

I also ran into this same issue and the solution works for me.