Allow for Projects resource to not manage associated repositories about terraform-provider-project HOT 6 CLOSED

@alexhung ☝️

from terraform-provider-project.

@chb0github We have a ticket for this, scheduled for current sprint for me to work on.

from terraform-provider-project.

Ok. So what you are saying is that,

1. repos a,b,c -> project1. but that
2. project1 in TF has no knowledge of this and so when you go to manage the project, it sends no repos ('cause they aren't configured in the project hcl) and thus blows them away

2 things

1. It seems to me that you're trying to manage the repos and the project entirely independently or inappropriately. For example, when you create the project you should be referencing the repo previously created in TF or vice versa. I mean, the only explanation that they are unaware of each other (and managed by TF) is because you didn't link them in HCL
2. Have you tried to import project state?

The reason this can't/doesn't work like groups/users is because those are managed by artifactory - in the same app. I mean, it requires some inside baseball explanation, but basically the jfrog platform is composed of several microservices and projects is a totally different micro service. You can take it up with the platform team in a support ticket

We really need to get some hcl and steps that repo this.

from terraform-provider-project.

@chb0github Sorry I didn't comment here earlier today. I started digging into this and found out why it may not be working as @mikeycmccarthy described.

In the project API, there's no way to get the repositories that are currently assigned to the project. So the code fetches all the repositories with the project key as the query in the repository API. This means after the read(), the project state now contains the repo keys, even though they were never specified in the HCL. This creates the relationships at the project side which is undesirable when the users want to manage it purely at the repository side.

I'm working on a PR that will break this undesirable link between project and repositories.

from terraform-provider-project.

@mikeycmccarthy By the way, I can't reproduce this behavior:

This does not seem to work the same way between projects and repositories. If I create a repository and include a project_key, if that repository then isn't in the list passed to projects (even if that attribute is missing) then the relationship is revoked.

The HCL I'm using:

# Required for Terraform 0.13 and up (https://www.terraform.io/upgrade-guides/0-13.html)
terraform {
  required_providers {
    project = {
      source  = "registry.terraform.io/jfrog/project"
      version = "1.1.2"
    }
    artifactory = {
      source  = "registry.terraform.io/jfrog/artifactory"
      version = "6.9.2"
    }
  }
}

provider "project" {
  //  supply ARTIFACTORY_USERNAME, _PASSWORD and _URL as env vars
}

provider "artifactory" {
  //  supply ARTIFACTORY_USERNAME, _PASSWORD and _URL as env vars
}

resource "project" "myproject" {
  key          = "myproj"
  display_name = "My Project"
  description  = "My Project"
  admin_privileges {
    manage_members   = true
    manage_resources = true
    index_resources  = true
  }
  max_storage_in_gibibytes   = 10
  block_deployments_on_limit = false
  email_notification         = true

  repos = []
}

resource "artifactory_remote_docker_repository" "remote-docker" {
  key                            = format("%s-remote-docker", project.myproject.key)
  project_key                    = project.myproject.key
  external_dependencies_enabled  = true
  external_dependencies_patterns = ["**/hub.docker.io/**", "**/bintray.jfrog.io/**"]
  enable_token_authentication    = true
  url                            = "https://hub.docker.io/"
  block_pushing_schema1          = true
}

The result in the remote repository myproject-remote-docker assigned to the project myproject.

Please provide an example HCL that doesn't work so we can investigate that.

from terraform-provider-project.

Upon talking with @alexhung and really thinking hard on this, I see this as a "works as designed" - We can reopen it with some more requests. It's not that it doesn't work, it just doesn't work as you'd prefer

from terraform-provider-project.