The latest update to [email protected] introduced a bug where you're only able to set the API keys for both current gen and next gen through environment variables.

Would like to reference Infrastructure_Definition as a Data Source.

Environment description is missing for both resource and data source

Hello there.
I am using terraform to template out some complex workflows in harness and running into an ordering issue on yaml files and I think it is because of the API, but not sure if something that should be handled in the go client/terraform.

Problem

Every time I run terraform apply we see differences using the harness_yaml_config even though nothing has changed.
This seems to be specific to workflows with verification providers using metric thresholds (i.e. fail fast if the metric is above 0), haven't run into this issue anywhere else.

Affected Resource(s)

harness_yaml_config

Debugging

I have traced this down to the GET call to config as code: https://app.harness.io/gateway/api/setup-as-code/yaml/workflows/<workflow>?accountId=<account>&appId=<appID>. On complex workflows with multiple verification providers I can get different sha256sums on the output. It seems to flop only between two differences and it's always the ordering on verification providers. It doesn't seem completely random fwiw and always flops between two different sha256sums.

Here's an example of the diff. https://gist.github.com/jadunham1/5ca349895502aaf6be7eebf840b1bfc5
If I apply this it will just do the revert in an apply or two back to the old way. It seems that the API does not preserve ordering of these yaml configs.

Expected Behavior

No differences in plan between runs

Actual Behavior

Differences in plan/apply ~50% of the time

Steps to Reproduce

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

1. Create a workflow with multiple prometheus verification timeseries to watch and metric thresholds set
2. terraform apply

Important Factoids

This only happens on workflows with verification providers and so far only prometheus verifications that I know of. It only happens when there are multiple verifications in a single verification provider.
It is easy to reproduce by just curling the output of the yaml setup-as-code endpoint and looking at the diff, it changes it's ordering.

I've encountered an issue while upgrading to the v0.1.7 provider. The terraform works fine with v0.1.6 but getting error decoding response happens with v0.1.6

The terraform in question is simple enough. I'm looping over a list of applications and then creating the resources from a string variable.

tfvars
applications = ["app1", "app2"]

main.tf

module "harness_apps" {
  source = "./modules/harness"
  for_each = var.applications
  applicationname = each.value

}

Creation of the application

resource "harness_applicatf intion" "this" {
  name = var.applicationname
}

Error Itself

│ Error: error decoding response: invalid character '<' looking for beginning of value
│
│   with module.harness_apps["app1"].harness_application.this,
│   on modules/harness/applicaction.tf line 1, in resource "harness_application" "this":
│    1: resource "harness_application" "this" {

Debug log Error - Looks like an nginx error, not familiar enough with the inner workings of tf providers as to guess why.

• Removed application Ids.

2021-12-14T10:02:50.355-0500 [INFO]  provider.terraform-provider-harness_v0.1.7: 2021/12/14 10:02:50 [DEBUG] GraphQL: Query {"query":"query($applicationId: String!) {\n\t\t\tapplication(applicationId: $applicationId) {\n\t\t\t\t\n\tid\n\tname\n\tdescription\n\tcreatedBy {\n\t\tid\n\t\tname\n\t\temail\n\t}\n\tgitSyncConfig {\n\t\tbranch\n\t\tgitConnector {\n\t\t\tid\n\t\t\tname\n\t\t\tbranch\n\t\t}\n\t\trepositoryName\n\t\tsyncEnabled\n\t}\n\ttags {\n\t\tname\n\t\tvalue\n\t}\t\n\t\n\t\t\t}\n\t\t}","variables":{"applicationId":"<remove_id_there was one here>"}}: timestamp=2021-12-14T10:02:50.355-0500
2021-12-14T10:02:50.355-0500 [INFO]  provider.terraform-provider-harness_v0.1.7: 2021/12/14 10:02:50 [DEBUG] GraphQL: Query {"query":"query($applicationId: String!) {\n\t\t\tapplication(applicationId: $applicationId) {\n\t\t\t\t\n\tid\n\tname\n\tdescription\n\tcreatedBy {\n\t\tid\n\t\tname\n\t\temail\n\t}\n\tgitSyncConfig {\n\t\tbranch\n\t\tgitConnector {\n\t\t\tid\n\t\t\tname\n\t\t\tbranch\n\t\t}\n\t\trepositoryName\n\t\tsyncEnabled\n\t}\n\ttags {\n\t\tname\n\t\tvalue\n\t}\t\n\t\n\t\t\t}\n\t\t}","variables":{"applicationId":"<remove_id_there was one here>"}}: timestamp=2021-12-14T10:02:50.355-0500
2021-12-14T10:02:50.355-0500 [INFO]  provider.terraform-provider-harness_v0.1.7: 2021/12/14 10:02:50 [DEBUG] GraphQL: Query {"query":"query($applicationId: String!) {\n\t\t\tapplication(applicationId: $applicationId) {\n\t\t\t\t\n\tid\n\tname\n\tdescription\n\tcreatedBy {\n\t\tid\n\t\tname\n\t\temail\n\t}\n\tgitSyncConfig {\n\t\tbranch\n\t\tgitConnector {\n\t\t\tid\n\t\t\tname\n\t\t\tbranch\n\t\t}\n\t\trepositoryName\n\t\tsyncEnabled\n\t}\n\ttags {\n\t\tname\n\t\tvalue\n\t}\t\n\t\n\t\t\t}\n\t\t}","variables":{"applicationId":"<remove_id_there was one here>"}}: timestamp=2021-12-14T10:02:50.355-0500
2021-12-14T10:02:50.355-0500 [INFO]  provider.terraform-provider-harness_v0.1.7: 2021/12/14 10:02:50 [DEBUG] GraphQL: Query {"query":"query($applicationId: String!) {\n\t\t\tapplication(applicationId: $applicationId) {\n\t\t\t\t\n\tid\n\tname\n\tdescription\n\tcreatedBy {\n\t\tid\n\t\tname\n\t\temail\n\t}\n\tgitSyncConfig {\n\t\tbranch\n\t\tgitConnector {\n\t\t\tid\n\t\t\tname\n\t\t\tbranch\n\t\t}\n\t\trepositoryName\n\t\tsyncEnabled\n\t}\n\ttags {\n\t\tname\n\t\tvalue\n\t}\t\n\t\n\t\t\t}\n\t\t}","variables":{"applicationId":"<remove_id_there was one here>"}}: timestamp=2021-12-14T10:02:50.355-0500
2021-12-14T10:02:50.665-0500 [INFO]  provider.terraform-provider-harness_v0.1.7: 2021/12/14 10:02:50 [TRACE] GraphQL response: <html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx</center>
</body>

Please let me know if there is anything else you need, or if I missed something obvious.

Thanks

Terraform Version

0.13

Affected Resource(s)

harness_yaml_config

Expected Behavior

When terraform destroy runs it should remove the YAML file that gets created in Harness.

Actual Behavior

Terraform state gets destroyed as expected but the YAML file that gets created in Harness isn't removed.

Steps to Reproduce

terraform apply
terraform destroy

Important Factoids

The path parameter for the harness_yaml_config resource is pointing to Workflows directory, ex:
Setup/Applications/app-name/Workflows/example-workflow.yaml

The YamlConfig resource cannot be deleted. The code for the provider is using the wrong client and method. It's attempting to delete a CloudProvider instead of using the ConfigAsCodeClient to remove the yaml document.

https://github.com/harness-io/terraform-provider-harness/blob/main/internal/service/cd/yamlconfig/yaml_config.go#L121

Terraform Version

1.0.11

Affected Resource(s)

Please list the resources as a list, for example:

• harness_yaml_config

Terraform Configuration Files

resource "harness_yaml_config" "service" {
  path    = "Setup/Applications/My Application/Services/my-service/Index.yaml"
  app_id  = ****
  content = <<EOF
harnessApiVersion: '1.0'
type: SERVICE
artifactType: AWS_LAMBDA
deploymentType: AWS_LAMBDA
description: My Lambda
EOF
}

Expected Behavior

Resource should have been deleted

Actual Behavior

Resource was not deleted

Steps to Reproduce

1. terraform apply
2. terraform destroy

Hi Harness Devs,

Thanks for a great TF Provider! one function that we would really like to have, is the ability to manage "Values YAML" Overrides in the harness_environment resource, in a similar way to how we can manage variable_override

thanks!

Would like to see this added as an option.
GraphQL api supports this:

mutation($secret: CreateSecretInput!){
  createSecret(input: $secret){
    secret{
      id,
      name
      ... on EncryptedText{
        name
        secretManagerId
        id
      }
      usageScope{
        appEnvScopes{
          application{
            filterType
            appId
          }
          environment{
            filterType
            envId
          }
        }
      }
    }
  }
}

Variables:

"secret": {
      "secretType": "ENCRYPTED_TEXT",
      "encryptedText": {
        "name": secret_name,
        "secretReference": secret_reference_name,
        "secretManagerId": secret_manager_id,
        "usageScope": {
          "appEnvScopes": [{
            "application": {
              "filterType": "ALL"
            },
            "environment": {
              "filterType": "PRODUCTION_ENVIRONMENTS"
            }
          }]
        }
      }
    }
  }

I've been trying to figure out the best way forward for supporting the next generation Harness platform with the Terraform provider. The provider was originally built for our first generation product which is continuous delivery only (referred to here on out as CD). Now that we have a lot of customers starting to use our next generation platform (referred to here on out as NG), which has a lot of different modules (i.e. feature flags, CI, CD, cloud cost management, etc.) we need to add support for it in the Terraform provider. Up until now, only a handful of resources have been implemented for it.

The challenge lies in how we name resources. For resources that are unique in NG it's pretty straightforward: harness_organization, harness_project, etc. There are no equivalent resource in CD for this. But for many others, there are. For example, harness_user, harness_service, harness_environment, etc.

There are a few ways I've thought we could address this.

Option 1: Prefix NG resources

Since the vast majority of users are currently using only CD resources we would leave those intact. For all new resources we would give them a prefix like harness_ng_service, and harness_ng_environment.

Pros

• No disruption to existing users having to migrate their resources.
• Allows both CD and NG to be used together in the same modules (is this really needed?)

Cons

• With the NG platform eventually becoming the only platform (CD will eventually be deprecated) it doesn't make a lot of sense to have _ng_ in every single resource.

Option 2: Prefix CD resources

Essentially this is the opposite of the first option. We would add a prefix for all CD resources like harness_cd_service, harness_cd_environment, harness_cd_yaml_config, etc.

Pros

• The NG platform resources (which will be the vast majority in the long run) will not have any prefix and follow the standard naming convention.
• Keeps the blast radius of the number or resources needing to have a prefix to a bare minimum

Cons

• Forces a renaming of all existing modules and state files to account for the new resources names. Will greatly affect existing users of CD.

Option 3: Split the codebase

This would entail creating a brand new provider with a completely separate codebase. The provider would be called something like harness/harness-platform as opposed to the current one which is calledharness/harness.

Pros

• No one currently using the provider for CD needs to change anything.
• Since the resource coverage of NG is so minimal, very few people would need to change anything and instead can just use the new provider when they start their implementation.
• No need to prefix any resources since they will be defined in two separate providers.

Cons

• Discoverability may be an issue and could cause confusion as to why there are two providers.

Option 4: Other ideas?

I'm really not sure what the best option is here. I'd love to hear other ideas, suggestions, or possibly votes for one of the other options.

Thanks!

Micah

Some terraform resources need values such has the harness-delegate hostname and uuid. It would be great if we could have a data source that could pull those values for use in the terraform resources.

Example: The cloud_provider resources need a delegate_selector.
Example: We are creating a terraform job that sets the Delegate's Scope with the Harness API. It needs the delegate's uuid.

The Harness API would likely be this one:

query {
  delegateList(
    filters: [{accountId: "<ACCOUNT_ID>" }]
  ){
nodes { 
      uuid
      delegateName
      delegateType
      description
      hostName
      lastHeartBeat
      ip
} }
}

Terraform Version

Run terraform -v to show the version. If you are not running the latest version of Terraform, please upgrade because your issue may have already been fixed.

Terraform v1.0.9
on darwin_amd64

Affected Resource(s)

Please list the resources as a list, for example:
terraform provider v0.1.15 for MAC and Linux

If this issue appears to affect multiple resources, it may be an issue with Terraform's core, so please mention this.

Terraform Configuration Files

terraform {
  required_providers {
    harness = {
      source  = "harness-io/harness"
      version = "0.1.15"
    }
  }
  required_version = ">=1.0.0"
}

When running terraform init, the following error appears:

Error: Incompatible provider version
│ 
│ Provider registry.terraform.io/harness-io/harness v0.1.15 does not have a package available for your current platform, darwin_amd64.
│ 
│ Provider releases are separate from Terraform CLI releases, so not all providers are available for all platforms. Other versions of this provider may have different
│ platforms supported.

Expected Behavior

Terraform should initialize properly

Actual Behavior

What actually happened?

Steps to Reproduce

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

1. terraform init

Important Factoids

Same error appears when running on Linux, in Terraform Cloud

The graphql API now supports adding custom scopes to a delegate.

Hi,

Terraform Version

1.0.0

Affected Resource(s)

• harness_cloudprovider_kubernetes

Expected Behavior

When selectors are updated for harness_cloudprovider_kubernetes resource, new selectors are being added instead of being replaced.

Actual Behavior

Selectors are added to value set in delegate_selectors

Steps to Reproduce

Create harness_cloudprovider_kubernetes resource and then try to update the delegate_selectors to a new value.

@abrahamkoshy

Customer wants the ability to initiate workflows and pipelines using terraform. This could possibly be done with resources like harness_execute_workflow or harness_execute_pipeline. It could possibly just be harness_execution if the API's are similar enough.

Version

Terraform v1.0.6
Harness 0.0.7

Affected Resource(s)

• harness_ssh_credential

Terraform Configuration Files

resource "tls_private_key" "harness_deploy_key" {
  algorithm = "RSA"
  rsa_bits  = 4096
}

data "harness_secret_manager" "secret_manager" {
  default = true
}

resource "harness_encrypted_text" "my_secret" {
  name = "my_secret"
  value             = tls_private_key.harness_deploy_key.private_key_pem
  secret_manager_id = data.harness_secret_manager.secret_manager.id
}

resource "harness_ssh_credential" "ssh_creds" {
  name = "ssh-test"
  ssh_authentication {
    port     = 22
    username = "git"
    inline_ssh {
      ssh_key_file_id = harness_encrypted_text.my_secret.id
    }
  }
}

Expected Behavior

terraform apply when run the second time, should cause no changes
state rm & import should work

Actual Behavior

Running apply second time caused an error

harness_ssh_credential.ssh_creds: Modifying... [id=6JH4djfxTA2_ntgbukKVlg]
╷
│ Error: The variables input contains a field name 'id' that is not defined for input object type 'SSHCredentialInput'
│
│   with harness_ssh_credential.ssh_creds,
│   on main.tf line 36, in resource "harness_ssh_credential" "ssh_creds":
│   36: resource "harness_ssh_credential" "ssh_creds" {

The Situation

• Through the Harness Manager we can create a harness_user and then add them to a harness_group (even if their email hasn't been verified yet)
• Through terraform the user must accept their invite to harness before we can add the user to the harness_group

Expected Behavior

Similarly to using the Harness Manager, we should be able to add users to groups without them having accepted the invite.

Terraform Output Details

Plan Output:

  # harness_add_user_to_group.group["[email protected]"] will be created
  + resource "harness_add_user_to_group" "group" {
      + group_id = "<group_id>"
      + id       = (known after apply)
      + user_id  = (known after apply)
    }

  # harness_user.users["[email protected]"] will be created
  + resource "harness_user" "users" {
      + email                              = "[email protected]"
      + id                                 = (known after apply)
      + is_email_verified                  = (known after apply)
      + is_imported_from_identity_provider = (known after apply)
      + is_password_expired                = (known after apply)
      + is_two_factor_auth_enabled         = (known after apply)
      + is_user_locked                     = (known after apply)
      + name                               = "[email protected]"
    }

Apply Output:

harness_user.users["[email protected]"]: Creating...
harness_user.users["[email protected]"]: Creation complete after 1s
harness_add_user_to_group.group["[email protected]"]: Creating...

Error: Exception while fetching data (/addUserToUserGroup) : Invalid request: User does not exist

  on file.tf line 145, in resource "harness_add_user_to_group" "group":
 145: resource "harness_add_user_to_group" "group" {

Further Analysis

$ terraform show 

# harness_user.users["[email protected]"]:
resource "harness_user" "users" {
    id                                 = "<user_id>"
    email                              = "[email protected]"
    name                               = "[email protected]"
    is_imported_from_identity_provider = false
    is_email_verified                  = false  # <- 'terraform show' shows the email isn't verified yet
    is_password_expired                = false
    is_two_factor_auth_enabled         = false
    is_user_locked                     = false
}

The terraform resource shows that the user's email hasn't been verified yet. All our companies other users have had their emails verified before we executed the terraform code. After the user accepted his invite (verified his email) the terraform passed and the user was added to the group.

Maybe the api-call /addUserToUserGroup fails if users have not been verified yet.

Why This Is An Issue

Our Operations team is blocked based how long it takes users to go into their email and accept the invite. Our Terraform code will keep failing until the user does so.

Hitting an error with the following stack trace on v0.1.8 when trying to approve a delegate:

│

│   with harness_delegate_approval.approval,

│   on main.tf line 2, in resource "harness_delegate_approval" "approval":

│    2: resource "harness_delegate_approval" "approval" {

│

│ The plugin encountered an error, and failed to respond to the

│ plugin.(*GRPCProvider).ApplyResourceChange call. The plugin logs may

│ contain more details.

╵

╷

│ Error: Plugin did not respond

│

│   with harness_cloudprovider_kubernetes.provider,

│   on main.tf line 24, in resource "harness_cloudprovider_kubernetes" "provider":

│   24: resource "harness_cloudprovider_kubernetes" "provider" {

│

│ The plugin encountered an error, and failed to respond to the

│ plugin.(*GRPCProvider).ApplyResourceChange call. The plugin logs may

│ contain more details.

╵

2022-01-13T17:14:50.151-0600 [TRACE] statemgr.Filesystem: removing lock metadata file terraform.tfstate.lock.info

2022-01-13T17:14:50.152-0600 [TRACE] statemgr.Filesystem: unlocked by closing terraform.tfstate

Stack trace from the terraform-provider-harness_v0.1.7.exe plugin:

panic: runtime error: invalid memory address or nil pointer dereference

[signal 0xc0000005 code=0x0 addr=0x90 pc=0xeb9795]

goroutine 38 [running]:

github.com/harness-io/terraform-provider-harness/internal/service/cd/delegate.resourceDelegateApprovalCreateOrUpdate(0x1250f88, 0xc0003099e0, 0xc0002c2580, 0xf86560, 0xc0004a6d50, 0xc0002a9f80, 0xb8a0b2, 0xc0002c2400)

        github.com/harness-io/terraform-provider-harness/internal/service/cd/delegate/delegate_approval.go:88 +0xd5

github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*Resource).create(0xc0004295e0, 0x1250f18, 0xc000393e40, 0xc0002c2580, 0xf86560, 0xc0004a6d50, 0x0, 0x0, 0x0)

        github.com/hashicorp/terraform-plugin-sdk/[email protected]/helper/schema/resource.go:341 +0x187

github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*Resource).Apply(0xc0004295e0, 0x1250f18, 0xc000393e40, 0xc00004b450, 0xc0002c2400, 0xf86560, 0xc0004a6d50, 0x0, 0x0, 0x0, ...)

        github.com/hashicorp/terraform-plugin-sdk/[email protected]/helper/schema/resource.go:467 +0x67b

github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*GRPCProviderServer).ApplyResourceChange(0xc0003900f0, 0x1250f18, 0xc000393e40, 0xc000528f00, 0x1123304, 0x12, 0x0)

        github.com/hashicorp/terraform-plugin-sdk/[email protected]/helper/schema/grpc_provider.go:977 +0xacf

github.com/hashicorp/terraform-plugin-go/tfprotov5/tf5server.(*server).ApplyResourceChange(0xc000172200, 0x1250fc0, 0xc000393e40, 0xc0001bc690, 0x0, 0x0, 0x0)

        github.com/hashicorp/[email protected]/tfprotov5/tf5server/server.go:603 +0x465

github.com/hashicorp/terraform-plugin-go/tfprotov5/internal/tfplugin5._Provider_ApplyResourceChange_Handler(0x10dcca0, 0xc000172200, 0x1250fc0, 0xc0002af590, 0xc0003090e0, 0x0, 0x1250fc0, 0xc0002af590, 0xc00047a240, 0xb3)

        github.com/hashicorp/[email protected]/tfprotov5/internal/tfplugin5/tfplugin5_grpc.pb.go:380 +0x222

google.golang.org/grpc.(*Server).processUnaryRPC(0xc0002cc700, 0x1258cb8, 0xc000317680, 0xc0002b2900, 0xc000300870, 0x1744220, 0x0, 0x0, 0x0)

        google.golang.org/[email protected]/server.go:1282 +0x52b

google.golang.org/grpc.(*Server).handleStream(0xc0002cc700, 0x1258cb8, 0xc000317680, 0xc0002b2900, 0x0)

        google.golang.org/[email protected]/server.go:1616 +0xd0c

google.golang.org/grpc.(*Server).serveStreams.func1.2(0xc000232200, 0xc0002cc700, 0x1258cb8, 0xc000317680, 0xc0002b2900)

        google.golang.org/[email protected]/server.go:921 +0xb2

created by google.golang.org/grpc.(*Server).serveStreams.func1

        google.golang.org/[email protected]/server.go:919 +0x1fd

Error: The terraform-provider-harness_v0.1.7.exe plugin crashed!

This is always indicative of a bug within the plugin. It would be immensely

helpful if you could report the crash with the plugin's maintainers so that it

can be fixed. The output above should help diagnose the issue.

2022-01-13T17:14:50.153-0600 [DEBUG] provider: plugin exited

Hi there,

Thank you for opening an issue. Please note that we try to keep the Terraform issue tracker reserved for bug reports and feature requests. For general usage questions, please see: https://www.terraform.io/community.html.

Terraform Version

Terraform v1.1.2
on linux_amd64

Affected Resource(s)

Terraform provider or Terraform core

If this issue appears to affect multiple resources, it may be an issue with Terraform's core, so please mention this.

Terraform Configuration Files

terraform {
  required_version = "~> 1.0"

  backend "remote" {
    hostname     = "app.terraform.io"
    organization = "something"

    workspaces {
      prefix = "something"
    }
  }

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 3.0"
    }
    harness = {
      source  = "harness/harness"
      version = "0.2.0"
    }
  }
}

provider "aws" {
  access_key = var.aws_access_key_id
  secret_key = var.aws_secret_access_key
  region     = var.aws_region

  default_tags {
    tags = {
      Application = var.application_name
      Environment = var.environment
    }
  }
}

provider "harness" {
  endpoint   = "https://app.harness.io/gateway"
  account_id = var.harness_account_id
  api_key    = var.harness_api_key
}

Debug Output

Please provider a link to a GitHub Gist containing the complete debug output: https://www.terraform.io/docs/internals/debugging.html. Please do NOT paste the debug output in the issue; just paste a link to the Gist.

Panic Output

If Terraform produced a panic, please provide a link to a GitHub Gist containing the output of the crash.log.

Expected Behavior

When running "terraform init", it should download and install the terraform provider properly.

Actual Behavior

I get the following error

│ Error: Failed to query available provider packages
│ 
│ Could not retrieve the list of available versions for provider hashicorp/harness: provider registry registry.terraform.io does not have a provider named registry.terraform.io/hashicorp/harness
│ 
│ Did you intend to use harness/harness? If so, you must specify that source address in each module which requires that provider. To see which modules are currently depending on hashicorp/harness, run the
│ following command:
│     terraform providers

Steps to Reproduce

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

1. terraform init

Important Factoids

Are there anything atypical about your accounts that we should know? For example: Running in EC2 Classic? Custom version of OpenStack? Tight ACLs?

References

Are there any other GitHub issues (open or closed) or Pull Requests that should be linked here? For example:

• #92

This is a similar case but not the exact version

If you create a cloudprovider with a usage scope for a specific application it will update it but every time you run a plan it will show there is a change.

resource "harness_application" "test" {
	name = "test-app"
}

resource "harness_cloudprovider_kubernetes" "test" {
	name = "test-cloudprovider"
	skip_validation = true

	authentication {
		delegate_selectors = ["test"]
	}

	usage_scope {
		application_filter_type = "SELECT"
		application_id = harness_application.test.id
		environment_filter_type = "NON_PRODUCTION_ENVIRONMENTS"
	}
}

After applying and running a plan you will see this:

Terraform used the selected providers to generate the following execution
        plan. Resource actions are indicated with the following symbols:
          ~ update in-place

        Terraform will perform the following actions:

          # harness_cloudprovider_kubernetes.test will be updated in-place
          ~ resource "harness_cloudprovider_kubernetes" "test" {
                id              = "<REDACTED>"
                name            = "test-cloudprovider"
                # (1 unchanged attribute hidden)


              - usage_scope {
                  - application_id          = "<REDACTEDL" -> null
                  - environment_filter_type = "NON_PRODUCTION_ENVIRONMENTS" -> null
                }
              + usage_scope {
                  + application_filter_type = "SELECT"
                  + application_id          = "<REDACTED>"
                  + environment_filter_type = "NON_PRODUCTION_ENVIRONMENTS"
                }
                # (1 unchanged block hidden)
            }

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

When turning on debug logging we should be able to clearly see all http request payloads and responses similar to what we see in the AWS terraform module. This will aid significantly in troubleshooting issues.

The graphql API now supports approving delegates.

Hi there,

Thank you for opening an issue. Please note that we try to keep the Terraform issue tracker reserved for bug reports and feature requests. For general usage questions, please see: https://www.terraform.io/community.html.

Terraform Version

1.0.0

Affected Resource(s)

Please list the resources as a list, for example:

• harness_environment

If this issue appears to affect multiple resources, it may be an issue with Terraform's core, so please mention this.

Terraform Configuration Files

resource "harness_environment" "test" {
  app_id = "Harness Application"
  name   = "Test"
  type   = "NON_PROD"

  variable_override {
    name         = "test"
    value        = "override"
    type         = "TEXT"
  }
}

Debug Output

Please provider a link to a GitHub Gist containing the complete debug output: https://www.terraform.io/docs/internals/debugging.html. Please do NOT paste the debug output in the issue; just paste a link to the Gist.

Panic Output

If Terraform produced a panic, please provide a link to a GitHub Gist containing the output of the crash.log.

Expected Behavior

Create a variable override for all services instead of defining on one service.

Actual Behavior

What actually happened?
When running the terraform plan, receive the error of:

The argument "service_name" is required, but no definition was found.

Steps to Reproduce

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

1. terraform apply

Important Factoids

Are there anything atypical about your accounts that we should know? For example: Running in EC2 Classic? Custom version of OpenStack? Tight ACLs?

References

Are there any other GitHub issues (open or closed) or Pull Requests that should be linked here? For example:

• GH-1234

Hi there,

Thank you for opening an issue. Please note that we try to keep the Terraform issue tracker reserved for bug reports and feature requests. For general usage questions, please see: https://www.terraform.io/community.html.

Terraform Version

Run terraform -v to show the version. If you are not running the latest version of Terraform, please upgrade because your issue may have already been fixed.

Affected Resource(s)

Please list the resources as a list, for example:

• harness_add_user_to_group
• harness_user

If this issue appears to affect multiple resources, it may be an issue with Terraform's core, so please mention this.

Terraform Configuration Files

resource "harness_user" "user" {
  count = length(local.users)
  email = local.users[count.index].email
  name  = local.users[count.index].email
}

resource "harness_add_user_to_group" "add_users_to_groups" {
  count    = length(local.users)
  group_id = harness_user_group.groups[local.users[count.index].groupType].id
  user_id  = harness_user.user[count.index].id
}

resource "harness_add_user_to_group" "add_users_to_readonly_group" {
  count    = length(local.users)
  group_id = var.read_only_group_id
  user_id  = harness_user.user[count.index].id
}

Debug Output

Please provider a link to a GitHub Gist containing the complete debug output: https://www.terraform.io/docs/internals/debugging.html. Please do NOT paste the debug output in the issue; just paste a link to the Gist.

Panic Output

If Terraform produced a panic, please provide a link to a GitHub Gist containing the output of the crash.log.

Expected Behavior

While creating Harness_user, harness_group and harness_add_user_to_group, it is failing with error: Error: Exception while fetching data (/addUserToUserGroup) : Invalid request: User does not exist
I think keeping add to group and user in seperate resource is not right solution. When we add user, it is always unverified and it seems adtogroup works if user is already verified. Add groups in harness_user resource to replicate graphQL API and UI behaviour.

Actual Behavior

Users should be created with groups.

Steps to Reproduce

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

1. terraform apply

Important Factoids

Are there anything atypical about your accounts that we should know? For example: Running in EC2 Classic? Custom version of OpenStack? Tight ACLs?

References

Are there any other GitHub issues (open or closed) or Pull Requests that should be linked here? For example:

• GH-1234

For on-prem customers the graphql endpoint is /api/graphql but for SaaS customers it's /gateway/api/graphql.

Need this issue fixed first in the sdk harness/harness-go-sdk#64

Hi,

Terraform Version

1.0.0

Affected Resource(s)

harness_delegate_approval

Expected Behavior

When terraform reruns apply on already approved resource it should recognize that the delegate was already approved and do nothing.

Actual Behavior

Terraform calls approval API however delegate is already approved and in enabled state hence approval resource is failed.

Steps to Reproduce

Approve a delegate with harness_delegate_approval resource and then rerun it.

@abrahamkoshy

When running a terraform plan that creates a harness_infrastructure_definition resource using the harness_environment data source for an environment that is not yet created, the plan fails with "The argument env_id is required but no definition was found."

The same fix should be applied for other data sources like the harness_application.

Terraform Version

v0.14.11

Affected Data Source(s)

• harness_environment
• harness_application

Debug Output

The argument env_id is required but no definition was found

Expected Behavior

The plan should have succeeded with the env_id field set to be computed during the apply run.

Actual Behavior

The plan failed because no definition was found for the env_id field.

Steps to Reproduce

1. terraform plan

References

https://github.com/hashicorp/terraform-provider-aws/blob/main/internal/service/ec2/host_data_source.go#L37-L40

https://github.com/harness-io/terraform-provider-harness/blob/main/internal/service/cd/environment/environment_data_source.go#L20

Maybe I am missing something obvious, but is there a way to create a "Infrastructure Provisioners" for a given Application?

https://docs.harness.io/article/o22jx8amxb-add-an-infra-provisioner

Creating new harness_connector resources at the account level resulted in a 404 Not Found error. Importing an existing connector at the account level produced a Cannot import non-existent remote object error.

The account id and API keys are set via environment variables, and I can successfully create and import other NG resources (harness_organization, for instance).

Terraform Version

❯ terraform --version
Terraform v1.1.3
on darwin_amd64

❯ terraform providers
Providers required by configuration:
.
└── provider[registry.terraform.io/harness-io/harness] ~> 0.1.7

Affected Resource(s)

• harness_connector
  • gcp
  • git
  • github

Terraform Configuration Files

• config file

Debug Output

• apply output
• import output

Expected Behavior

The apply command should have created the resource in Harness NG at the account level.
The import command should have imported the resource in Harness NG at the account level.

Actual Behavior

The terraform apply command produced a 404 Not Found error
The terraform import command produced a Cannot import non-existent remote object error

Steps to Reproduce

• terraform apply
• Manually create the resource in Harness NG
• terraform import 'harness_connector.example' example_connector_f842600c

Important Factoids

• Environment variables are used to configure the provider
  • harness_organization can be used successfully (both create and import)
• The same behavior was observed with the git and github connector types, though I've only included config/output for the gcp type. Let me know if you need it for the others as well.

Current State

This is specific to Harness First Generation

The harness_user_group resource is used to set up a group within Access Management for Harness. This harness_user_group resource includes the name, description, account_permissions, and app_permissions - amongst other settings for the group.

In our use case, the harness_user_group resources are set up as a part of the terraform that sets up the account-level settings for our Harness account, including SAML and SCIM.

We set up our applications separately from the account-level setup, by exposing a module for a template application that is used to set up instances of Harness applications. Because of this, we end up creating harness_user_group instances that are specific to the application, instead of leveraging harness_user_group instances that are created as part of the system-level setup that leverages SCIM.

Ask

We'd like to be able to assign permissions for the application as a part of the terraform for that application. We can't set up application permissions using the system-level setup without having to constantly update the harness_user_group in the terraform for the system-level setup. But, we would still like to assign permissions to applications being created by referencing the user groups that are created as a part of the SCIM setup for Harness.

Our ask is to create a new resource, similar to the harness_add_user_to_group resource, that lets us set up permissions for an existing harness_user_group to the instance of the harness_application that we create in the application-level terraform. In theory, this provider would need data sources for harness_application and harness_user_group and would take the id (or similar) for those data sources as inputs (as well as the application permissions themselves) - which is great because data sources for harness_application and harness_user_group already exist (and it looks like the id property is exposed for both)!

Apologies in advance if the prescriptive nature of this Issue is offensive!

When trying to import the terraform harness provider, it gives an error because data.harness_current_user creates a function that starts with a number, which isn't supported in golang or python. To my knowledge most languages don't support naming anything with a number, which will cause auto-generation of libraries (see CDKTF).

Terraform Version

Run terraform -v to show the version. If you are not running the latest version of Terraform, please upgrade because your issue may have already been fixed.
Terraform v1.1.4
on darwin_arm64

Affected Resource(s)

Please list the resources as a list, for example:

• data. harness_current_user

If this issue appears to affect multiple resources, it may be an issue with Terraform's core, so please mention this.

Terraform Configuration Files

# Copy-paste your Terraform configurations here - for large Terraform configs,
# please use a service like Dropbox and share a link to the ZIP file. For
# security, you can also encrypt the files using our GPG public key.

Not relevant for this problem.

Debug Output

Please provider a link to a GitHub Gist containing the complete debug output: https://www.terraform.io/docs/internals/debugging.html. Please do NOT paste the debug output in the issue; just paste a link to the Gist.
https://gist.github.com/eahrend/63d6bf343d99a7b5486faf459d0c1c33

Panic Output

If Terraform produced a panic, please provide a link to a GitHub Gist containing the output of the crash.log.

Expected Behavior

What should have happened?
Running cdktf get generates code.

Actual Behavior

What actually happened?
Panics when trying to create the cdktf code.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:
Create a cdktf.json file

{
    "language": "go",
    "app": "go run .",
    "codeMakerOutput": "generated",
    "projectId": "####",
    "terraformProviders": [
        "hashicorp/google@~>4.9.0",
        "hashicorp/google-beta@~>4.9.0",
        "hashicorp/helm@~>2.4.1",
        "hashicorp/kubernetes@~>2.7.1",
        "harness-io/harness@~>0.1.12"
    ],
    "terraformModules": [
        {
            "name": "projectFactory",
            "source": "terraform-google-modules/project-factory/google",
            "version": "~> 11.3.1"
        },
        {
            "name":"cloudRouter",
            "source": "terraform-google-modules/cloud-router/google",
            "version": "~> 1.3.0"
        },
        {
            "name": "mySQL",
            "source":"GoogleCloudPlatform/sql-db/google//modules/mysql",
            "version": "~> 9.0.0"
        },
        {
            "name":"gke",
            "source": "terraform-google-modules/kubernetes-engine/google//modules/beta-private-cluster",
            "version":"~> 19.0.0"
        }
    ],
    "context": {
        "excludeStackIdFromLogicalIds": "true",
        "allowSepCharsInLogicalIds": "true"
    }
}

Run cdktf get

Attempt to change the name of cloud provider fails. This causes

2021/10/11 13:38:57 [ERROR] eval: *terraform.EvalRefresh, err: received http status code '400'
2021/10/11 13:38:57 [ERROR] eval: *terraform.EvalSequence, err: received http status code '400'

Error: received http status code '400'
to be returned by terraform. The state file does get updated however and has the right name.

After renaming provider manually in UI as well as selecting associated Service Account Token works and fixes the above error.

While updating secrets across multiple instances we hit a limit with our key.
Even thought the call to harness failed, the state file was updated with new key anyway. The next time apply ran it skipped this resource since it considered it updated. This caused the connector to stop working.

Error: Exception while fetching data (/updateSecret) : Invalid request: User not authorized
with module.app.harness_encrypted_text.git_secret,
on .terraform/modules/app/main.tf line 59, in resource "harness_encrypted_text" "git_secret":
59: resource "harness_encrypted_text" "git_secret" {

Hi there,

Terraform Version

1.0.0

Affected Resource(s)

NA

Expected Behavior

Any change in verbosity of the Log level should not show the Harness API key in X-Api-Key field of the HTTP Request.

Actual Behavior

When we turn on the Log level to TRACE or DEBUG level, the log shows Harness API key (X-Api-Key value) in plain text HTTP Request body.

Steps to Reproduce

1. export TF_LOG=TRACE
2. terraform plan or terraform apply
3. Check for X-Api-Key value in any of the HTTP Request body

@abrahamkoshy

Need the ability to create Triggers.

Currently the only way to look up a git connector is by Id. This is pretty challenging because it's not surfaced anywhere in the UI. The only way to find it is listing all the connectors in the graphql API and filtering down to the one you're looking for.

We have been facing multiple issues with the latest harness provider version 0.1.14 while trying to run our harness terraform modules. Everything works fine on the older version 0.1.9 and breaks on this newest version. We have tested the latest version across four of our modules and each one is failing within its PLAN/APPLY phase.

Terraform Version

Terraform v1.0.0

Affected Resource(s)

1. harness_delegate_approval
2. harness_yaml_config
3. harness_service_kubernetes
4. harness_application

Debug Output

1. harness_delegate_approval - The plugin encountered an error, and failed to respond to the plugin.(*GRPCProvider).ReadDataSource call.
2. harness_yaml_config - Error: received http status code '404'
3. harness_service_kubernetes - The argument "app_id" is required, but no definition was found
4. harness_application - The plugin encountered an error, and failed to respond to the plugin.(*GRPCProvider).ApplyResourceChange call

Expected Behavior

Based on affected resources number list

1. The plan should have succeeded without the plugin crash error
2. Apply should be succeeded without the HTTP 404 error
3. The plan should have succeeded with the env_id field set to be computed during the apply run
4. The plan should have succeeded without the plugin crash error

Actual Behavior

Based on affected resources number list

1. The plan failed because the plugin encountered an error, and failed to respond to the plugin
2. Apply failed throwing HTTP 404 error
3. The plan failed because no definition was found for the env_id field
4. Plan failed because the plugin encountered an error, and failed to respond to the plugin

Steps to Reproduce

1. terraform plan
2. terraform apply

Git sync setup works great, however if change is made in the UI and a different repository is selected as git sync destination, the provider does not detect drift next time plan is ran.

Is this a limitation of the API?

In the README, the link for "Provider usage" is broken. Currently it points to https://registry.terraform.io/providers/harness/harness/latest/docs which gives 404. It looks like it is a relic of the move from the harness-io org, since this link seems to work: https://registry.terraform.io/providers/harness-io/harness/latest/docs

Hi,

Terraform Version

1.0.0

Affected Resource(s)

• harness_environment

Terraform Configuration Files

variable "environment_map" {
      type      = map(string)
      default   = {
        "DEV"  = "NON_PROD",
        "UAT"   = "NON_PROD",
        "OTH"   = "NON_PROD",
        "PROD" = "PROD"
    }
}

resource "harness_environment" "environments" {
    for_each = var.environment_map
    app_id   = "XXXXXXX"
    name    = each.key
    type     = each.value
}

Expected Behavior

Environments will be created without without any issue.

Actual Behavior

Apply facing the following error sometimes:

Error: Provider produced inconsistent result after apply

When applying changes to
module.harness.harness_environment.environments["DEV"],
provider "registry.terraform.io/harness/harness" produced an unexpected new value: Root 
resource 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

1. Create the configuration based on above code
2. terraform apply

@abrahamkoshy

I was browsing through the code and the documentation and saw that there are references with an AWS Helm Service. Is this a typo?

https://github.com/harness-io/terraform-provider-harness/blob/395a2023cd7ad7330de317a5f7bc00d4cbca8f46/internal/provider/resource_service_helm.go#L14

Since the documentation is generated from code, the docs are as well showcasing this nomenclature.
https://github.com/harness-io/terraform-provider-harness/blob/main/docs/resources/service_helm.md#harness_service_helm-resource

Hi,

I am trying to implement your Terraform Provider for Harness NextGen. It has been told to me that NextGen is not supported for this provider. Is there a plan for this in the future? If so, when?

Hi there,

The Terraform Provider for Harness appears to be broken. We attempted to import the github connector and it threw some go-lang error stacks when using an import command.
We used this command - "import module.control.harness_connector.github_marqeta marqetajposharnessnextgen"
Please see more detail about our tfplan and errors in the attached photos.

Ticket ref - https://support.harness.io/hc/en-us/requests/21831

Expected Behavior

What should have happened?

Be able to get all delegates running in kubernetes that are enabled!

data "harness_delegate" "example" {
type = "KUBERNETES"
status = "ENABLED"
}

Actual Behavior

What actually happened?

name is required, so it is not possible!

We should have automated changelogs generated for each release. The best option is to model it after terraform-provider-aws which leverages https://github.com/hashicorp/go-changelog.

Would like to be able to create API keys via terraform
GraphQL API now supports it

Hi there,

Terraform provider does not support Expressions whereas Expressions are currently reflected in the Harness SDK. We are deploying harness resources Service, Infrastructure definition, Workflows, pipelines through terraform. We are facing issue to undefine Expressions in Infrastructure definition.

You can refer the error herewith,

module.harness-deploy.harness_infrastructure_definition.test-Infradef: Creating...
╷
│ Error: FAILED**: Invalid request: Expressions can't be empty with provisioner
│
│ with module.harness-deploy.harness_infrastructure_definition.test-Infradef,
│ on ../services.tf line 15, in resource "harness_infrastructure_definition" "test-Infradef":
│ 15: resource "harness_infrastructure_definition" "test-Infradef" {

Here we are not sure, how to provide Expressions through terraform. Since Expressions are not reflected in provider. We are trying to deploy Harness pipeline and workflow through terraform. We are stuck here with Infrastructure definition Expression.

Please help us here to resolve this issue.

Affected Resource(s)

Please list the resources as a list, for example:

• harness_cloudprovider_kubernetes
• harness_environment

If this issue appears to affect multiple resources, it may be an issue with Terraform's core, so please mention this.

Terraform Configuration Files

data "harness_application" "altair" {
  for_each = toset(var.application_names)
  name     = each.value
}

resource "harness_cloudprovider_kubernetes" "altair_k8s" {
  depends_on = [
    kubectl_manifest.stateful_set
  ]
  name            = var.cloud_provider_name
  skip_validation = false

  authentication {
    delegate_selectors = ["${var.delegate_name}"]
  }
  dynamic "usage_scope" {
    for_each = data.harness_application.altair
    content {
      application_id = usage_scope.value.id
      environment_filter_type = "PRODUCTION_ENVIRONMENTS"
    }
  }
}

resource "harness_environment" "altair_env" {
  for_each = data.harness_application.altair
  app_id   = each.value.id
  name     = var.environment_name
  type     = var.environment_type
}

Expected Behavior

Resources should wait until data sources are computed

# module.harness_delegate.harness_cloudprovider_kubernetes.altair_k8s will be created
  + resource "harness_cloudprovider_kubernetes" "altair_k8s" {
      + id              = (known after apply)
      + name            = "infra"
      + skip_validation = false

      + authentication {
          + delegate_selectors = [
              + "infra",
            ]
        }

      + usage_scope {} => know after apply
      + usage_scope {} => know after apply
    }
# module.harness_delegate.harness_environment.altair_env will be created
  resource "harness_environment" "altair_env" {
    app_id   = (known after apply)
    name     = "infra"
    type     = "PROD"
  }

Actual Behavior

Resource created without user scope for cloudprovider and harness environment creation failed with no definition was found

# module.harness_delegate.harness_cloudprovider_kubernetes.altair_k8s will be created
  + resource "harness_cloudprovider_kubernetes" "altair_k8s" {
      + id              = (known after apply)
      + name            = "altair-infra"
      + skip_validation = false

      + authentication {
          + delegate_selectors = [
              + "altair-infra",
            ]
        }

      + usage_scope {}
    }

Error: Missing required argument

  on .terraform/modules/harness_delegate/environment.tf line 6, in resource "harness_environment" "altair_env":
   6:   app_id   = each.value.id

The argument "app_id" is required, but no definition was found.

Steps to Reproduce

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

1. Add datasource to retrieve application id
2. Link this to any other resource like cloud provider or environment
3. Run terraform apply