Where does a user get blueprint_id from? It's not listed in the GUI, the only way I am aware is getting it through VCS-CLI or API.
Why don't we support blueprint_name as parameter?

The documentation, i.e. syntax examples, to properly identify networks on machine resources and to use vRA constraint tags to select the correct network profile is non-existent. We have been unable to work through the proper terraform yaml to select a network profile and attach a machine to the existing network.

Is it possible to add the creation of a blueprint as a terraform vRA resource? I see the ability in the blueprint API section, but I don’t see a blueprint resource in the current terraform provider. This would allow a terraform user to generate the vRA specific yaml and execute it through a single terraform plan, instead of requiring separate actions within vRA itself.

To ease installation for non-developers you should add instruction:

• where to download binary (link to releases)
• how to extract binary
• where to put provider file (.terraform.d/plugins)

Investigate if deleting a machine automatically deletes all the attached disks irrespective of disk type. Fix the logic in resource machine delete based on findings from the investigation.

Thanks for open sourcing terraform-provider-vra!

I see there is a website directory within which are Terraform-style documentation .md files. However, many of these files are empty. As a potential user of terraform-provider-vra, it would be very useful to be able to read provider documentation.

Thanks!

Day 2 operations like resize, attach disk etc should be support as part of update machine operation

terraform config file (.tf)

provider "cas" {
url = "https://api.staging.symphony-dev.com"
refresh_token = "xxxxxxxxxxxxxxxxxxxx"
deployment_id = "cas_machine_tf_test"
}

resource "cas_machine" "my_ubuntu_machine" {
name = "terraform_provider_cas_machine"
flavor = "small"
image = "ubuntu"
}

After running terraform apply and approving the plan I see the below error

Error: Error applying plan:

1 error(s) occurred:

• cas_machine.my_ubuntu_machine: 1 error(s) occurred:

• cas_machine.my_ubuntu_machine:
  Request: /iaas/machines create resource
  POST https://api.staging.symphony-dev.com/iaas/machines HTTP/1.1
  Host: api.staging.symphony-dev.com
  authorization: xxxxxxxxxxxxxxxxxxxxxxxxxxxx
  content-type: application/json
  {"name":"terraform_provider_cas_machine","image":"ubuntu","flavor":"small","projectId":"a2144353-b449-4844-9191-e3087c1dcafb","machineCount":1,"customProperties":{"__composition_context_id":"cas_machine_tf_test"},"nics":[]}
  Response status code: 201
  Response body: {"progress":0,"status":"INPROGRESS","name":"Provisioning","id":"d21b1de9dcb252755861d87253b38","selfLink":"/iaas/api/request-tracker/d21b1de9dcb252755861d87253b38"}

Terraform does not automatically rollback in the face of errors.
Instead, your Terraform state file has been partially updated with
any resources that successfully completed. Please address the error
above and apply again to incrementally change your infrastructure.

A data source for cloud_account_vsphere has not been implemented yet.

Disk and Storage profile syntax and formatting documentation is non existent. As with the networks, please give us an example usage to select and use storage profiles

data vra_fabric_network doesnt work

data "vra_fabric_network" "my-fabric-network" {
filter = "name eq 'PortGroupName'"
}

HQSML-1712491:bin mdittb638$ TF_LOG=1 VRA_DEBUG=1 terraform apply
2019/11/04 12:54:33 [WARN] Invalid log level: "1". Defaulting to level: TRACE. Valid levels are: [TRACE DEBUG INFO WARN ERROR]
data.vra_project.this: Refreshing state...
data.vra_fabric_network.my-fabric-network: Refreshing state...
data.vra_cloud_account_vsphere.this: Refreshing state...
data.vra_network.this: Refreshing state...

Error: unknown error (status 400): {resp:0xc0005b81b0}

on main.tf line 40, in data "vra_fabric_network" "my-fabric-network":
40: data "vra_fabric_network" "my-fabric-network" {

When performing a terraform apply for a plan that deploys an existing blueprint, terraform crashes. The error shown in the command window is attached below, and the crash.log file is attached.

cdombrowski-a01:bin cdombrowski$ terraform apply
data.vra_project.this: Refreshing state...
data.vra_cloud_account_vsphere.this: Refreshing state...

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:

vra_deployment.this will be created

• resource "vra_deployment" "this" {
  • blueprint_id = "9b0d6fd9-2520-46a0-9927-5f49750555a3"
  • blueprint_version = "4"
  • catalog_item_id = (known after apply)
  • catalog_item_version = (known after apply)
  • created_at = (known after apply)
  • created_by = (known after apply)
  • description = "terraform test deployment"
  • expand_last_request = true
  • expand_resources = true
  • expense = (known after apply)
  • id = (known after apply)
  • inputs = {
    • "inCMI" = "Cloud-init"
    • "inCount" = "3"
    • "inFlavor" = "c5.large"
    • "inLicense" = "rhat"
    • "inRail" = "protected"
    • "inTenant" = "A"
    • "vmName" = "chrisd_terraform"
      }
  • last_updated_at = (known after apply)
  • last_updated_by = (known after apply)
  • lease_expire_at = (known after apply)
  • name = "chrisd_terraform"
  • project = (known after apply)
  • project_id = "79b572c5-92f4-4cbc-bacc-d9e7b7b09f84"
  • resources = (known after apply)
  • simulated = (known after apply)
  • status = (known after apply)
    }

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

vra_deployment.this: Creating...
vra_deployment.this: Still creating... [10s elapsed]
vra_deployment.this: Still creating... [20s elapsed]
vra_deployment.this: Still creating... [30s elapsed]
vra_deployment.this: Still creating... [40s elapsed]
vra_deployment.this: Still creating... [50s elapsed]
vra_deployment.this: Still creating... [1m0s elapsed]
vra_deployment.this: Still creating... [1m10s elapsed]
vra_deployment.this: Still creating... [1m20s elapsed]
vra_deployment.this: Still creating... [1m30s elapsed]
vra_deployment.this: Still creating... [1m40s elapsed]
vra_deployment.this: Still creating... [1m50s elapsed]
vra_deployment.this: Still creating... [2m0s elapsed]
vra_deployment.this: Still creating... [2m10s elapsed]

Error: rpc error: code = Unavailable desc = transport is closing

panic: interface conversion: interface {} is json.Number, not string
2019-11-11T11:04:09.481-0500 [DEBUG] plugin.terraform-provider-vra:
2019-11-11T11:04:09.481-0500 [DEBUG] plugin.terraform-provider-vra: goroutine 12 [running]:
2019-11-11T11:04:09.481-0500 [DEBUG] plugin.terraform-provider-vra: github.com/vmware/terraform-provider-vra/vra.expandInputs(0x1db28a0, 0xc000582450, 0x7)
2019-11-11T11:04:09.481-0500 [DEBUG] plugin.terraform-provider-vra: /Users/markpeek/github/vmware/terraform-provider-vra/vra/structure.go:148 +0x175
2019-11-11T11:04:09.481-0500 [DEBUG] plugin.terraform-provider-vra: github.com/vmware/terraform-provider-vra/vra.resourceDeploymentRead(0xc0004bcb60, 0x1cf1ac0, 0xc0005ac8c0, 0x1, 0x1)
2019-11-11T11:04:09.481-0500 [DEBUG] plugin.terraform-provider-vra: /Users/markpeek/github/vmware/terraform-provider-vra/vra/resource_deployment.go:353 +0xe78
2019-11-11T11:04:09.481-0500 [DEBUG] plugin.terraform-provider-vra: github.com/vmware/terraform-provider-vra/vra.resourceDeploymentCreate(0xc0004bcb60, 0x1cf1ac0, 0xc0005ac8c0, 0x2, 0x2cf66c0)
2019-11-11T11:04:09.481-0500 [DEBUG] plugin.terraform-provider-vra: /Users/markpeek/github/vmware/terraform-provider-vra/vra/resource_deployment.go:276 +0xb7e
2019-11-11T11:04:09.481-0500 [DEBUG] plugin.terraform-provider-vra: github.com/hashicorp/terraform-plugin-sdk/helper/schema.(*Resource).Apply(0xc000441380, 0xc0006523c0, 0xc0005acbe0, 0x1cf1ac0, 0xc0005ac8c0, 0x1, 0xc0007c8c08, 0x1db04a0)
2019-11-11T11:04:09.481-0500 [DEBUG] plugin.terraform-provider-vra: /Users/markpeek/go/pkg/mod/github.com/hashicorp/[email protected]/helper/schema/resource.go:305 +0x3b4
2019-11-11T11:04:09.481-0500 [DEBUG] plugin.terraform-provider-vra: github.com/hashicorp/terraform-plugin-sdk/helper/schema.(*Provider).Apply(0xc0005fe500, 0xc00064fa68, 0xc0006523c0, 0xc0005acbe0, 0xc0000cef28, 0xc0000be3b8, 0x1db28a0)
2019-11-11T11:04:09.481-0500 [DEBUG] plugin.terraform-provider-vra: /Users/markpeek/go/pkg/mod/github.com/hashicorp/[email protected]/helper/schema/provider.go:294 +0x18f
2019-11-11T11:04:09.481-0500 [DEBUG] plugin.terraform-provider-vra: github.com/hashicorp/terraform-plugin-sdk/internal/helper/plugin.(*GRPCProviderServer).ApplyResourceChange(0xc00000e008, 0x2244f60, 0xc0001b6210, 0xc00023a120, 0xc00000e008, 0xc0001b6210, 0xc0007b3bd0)
2019-11-11T11:04:09.481-0500 [DEBUG] plugin.terraform-provider-vra: /Users/markpeek/go/pkg/mod/github.com/hashicorp/[email protected]/internal/helper/plugin/grpc_provider.go:885 +0x884
2019-11-11T11:04:09.481-0500 [DEBUG] plugin.terraform-provider-vra: github.com/hashicorp/terraform-plugin-sdk/internal/tfplugin5._Provider_ApplyResourceChange_Handler(0x1f48f00, 0xc00000e008, 0x2244f60, 0xc0001b6210, 0xc00023a0c0, 0x0, 0x2244f60, 0xc0001b6210, 0xc000168000, 0x4fa)
2019-11-11T11:04:09.481-0500 [DEBUG] plugin.terraform-provider-vra: /Users/markpeek/go/pkg/mod/github.com/hashicorp/[email protected]/internal/tfplugin5/tfplugin5.pb.go:3189 +0x23e
2019-11-11T11:04:09.481-0500 [DEBUG] plugin.terraform-provider-vra: google.golang.org/grpc.(*Server).processUnaryRPC(0xc0000d82c0, 0x2252e40, 0xc000558d80, 0xc000140000, 0xc00029b0b0, 0x2cc4e80, 0x0, 0x0, 0x0)
2019-11-11T11:04:09.481-0500 [DEBUG] plugin.terraform-provider-vra: /Users/markpeek/go/pkg/mod/google.golang.org/[email protected]/server.go:995 +0x466
2019-11-11T11:04:09.481-0500 [DEBUG] plugin.terraform-provider-vra: google.golang.org/grpc.(*Server).handleStream(0xc0000d82c0, 0x2252e40, 0xc000558d80, 0xc000140000, 0x0)
2019-11-11T11:04:09.481-0500 [DEBUG] plugin.terraform-provider-vra: /Users/markpeek/go/pkg/mod/google.golang.org/[email protected]/server.go:1275 +0xda6
2019-11-11T11:04:09.482-0500 [DEBUG] plugin.terraform-provider-vra: google.golang.org/grpc.(*Server).serveStreams.func1.1(0xc0002b4040, 0xc0000d82c0, 0x2252e40, 0xc000558d80, 0xc000140000)
2019-11-11T11:04:09.482-0500 [DEBUG] plugin.terraform-provider-vra: /Users/markpeek/go/pkg/mod/google.golang.org/[email protected]/server.go:710 +0x9f
2019-11-11T11:04:09.482-0500 [DEBUG] plugin.terraform-provider-vra: created by google.golang.org/grpc.(*Server).serveStreams.func1
2019-11-11T11:04:09.482-0500 [DEBUG] plugin.terraform-provider-vra: /Users/markpeek/go/pkg/mod/google.golang.org/[email protected]/server.go:708 +0xa1
2019/11/11 11:04:09 [DEBUG] vra_deployment.this: apply errored, but we're indicating that via the Error pointer rather than returning it: rpc error: code = Unavailable desc = transport is closing
2019/11/11 11:04:09 [TRACE] : eval: *terraform.EvalMaybeTainted
2019/11/11 11:04:09 [TRACE] EvalMaybeTainted: vra_deployment.this encountered an error during creation, so it is now marked as tainted
2019/11/11 11:04:09 [TRACE] : eval: *terraform.EvalWriteState
2019/11/11 11:04:09 [TRACE] EvalWriteState: removing state object for vra_deployment.this
2019/11/11 11:04:09 [TRACE] : eval: *terraform.EvalApplyProvisioners
2019/11/11 11:04:09 [TRACE] EvalApplyProvisioners: vra_deployment.this has no state, so skipping provisioners
2019/11/11 11:04:09 [TRACE] : eval: *terraform.EvalMaybeTainted
2019/11/11 11:04:09 [TRACE] EvalMaybeTainted: vra_deployment.this encountered an error during creation, so it is now marked as tainted
2019/11/11 11:04:09 [TRACE] : eval: *terraform.EvalWriteState
2019/11/11 11:04:09 [TRACE] EvalWriteState: removing state object for vra_deployment.this
2019/11/11 11:04:09 [TRACE] : eval: *terraform.EvalIf
2019/11/11 11:04:09 [TRACE] : eval: *terraform.EvalIf
2019/11/11 11:04:09 [TRACE] : eval: *terraform.EvalWriteDiff
2019/11/11 11:04:09 [TRACE] : eval: *terraform.EvalApplyPost
2019/11/11 11:04:09 [ERROR] : eval: *terraform.EvalApplyPost, err: rpc error: code = Unavailable desc = transport is closing
2019/11/11 11:04:09 [ERROR] : eval: *terraform.EvalSequence, err: rpc error: code = Unavailable desc = transport is closing
2019/11/11 11:04:09 [TRACE] [walkApply] Exiting eval tree: vra_deployment.this
2019/11/11 11:04:09 [TRACE] vertex "vra_deployment.this": visit complete
2019/11/11 11:04:09 [TRACE] dag/walk: upstream of "meta.count-boundary (EachMode fixup)" errored, so skipping
2019-11-11T11:04:09.484-0500 [DEBUG] plugin: plugin process exited: path=/Users/cdombrowski/terraform/bin/terraform-provider-vra pid=7278 error="exit status 2"
2019/11/11 11:04:09 [TRACE] dag/walk: upstream of "provider.vra (close)" errored, so skipping
2019/11/11 11:04:09 [TRACE] dag/walk: upstream of "root" errored, so skipping
2019/11/11 11:04:09 [TRACE] statemgr.Filesystem: creating backup snapshot at terraform.tfstate.backup
2019/11/11 11:04:09 [TRACE] statemgr.Filesystem: state has changed since last snapshot, so incrementing serial to 108
2019/11/11 11:04:09 [TRACE] statemgr.Filesystem: writing snapshot at terraform.tfstate
2019/11/11 11:04:09 [TRACE] statemgr.Filesystem: removing lock metadata file .terraform.tfstate.lock.info
2019/11/11 11:04:09 [TRACE] statemgr.Filesystem: unlocking terraform.tfstate using fcntl flock
2019-11-11T11:04:09.498-0500 [DEBUG] plugin: plugin exited

!!!!!!!!!!!!!!!!!!!!!!!!!!! TERRAFORM CRASH !!!!!!!!!!!!!!!!!!!!!!!!!!!!

Terraform crashed! This is always indicative of a bug within Terraform.
A crash log has been placed at "crash.log" relative to your current
working directory. It would be immensely helpful if you could please
report the crash with Terraform1 so that we can fix this.

When reporting bugs, please include your terraform version. That
information is available on the first line of crash.log. You can also
get it by running 'terraform --version' on the command line.

!!!!!!!!!!!!!!!!!!!!!!!!!!! TERRAFORM CRASH !!!!!!!!!!!!!!!!!!!!!!!!!!!!

crash.log

I created an empty deployment through UI (ID: bd18dfd2-3ad1-4e01-814d-4c87c899235b) in vRA8, And created two machines using terraform provider

provider "vra" {
url = var.url
refresh_token = var.refresh_token
insecure = var.insecure
}

data "vra_project" "this" {
name = "e2e-terraform-vra-prithvish"
}

resource "vra_machine" "vms" {
count = var.instance_count
description = "terrafrom test machine"
project_id = data.vra_project.this.id
deployment_id = "bd18dfd2-3ad1-4e01-814d-4c87c899235b"
name = "tf-machine"
image = "ubuntu"
flavor = "small"
tags {
key = "foo"
value = "bar"
}
tags {
key = "OS"
value = "Ubuntu"
}
timeouts {
create = "20m"
}
}

The machines got provisioned successfully however the machines didn't get associated to the pre-created deployment. When I checked the machine document by doing the GET call, I noticed that the machine customProperties is missing "__deployment_id": attribute.

Can someone share/update the documentation to indicate what version(s) of vRA this provider supports? Current documentation seems to reference CAS/vRA 8 things, but I'm not sure if that's accurate.

Requesting support for fabric-vsphere-storage-policies & fabric-vsphere-datastores data source to avoid hardcoding of storagePolicyId & datastoreId when creating vsphere storage profiles

Got this stack trace when refreshing and got a 404 from the cloud proxy (not connected). This is due to dereferencing getResp when it is nil on this line.

panic: runtime error: invalid memory address or nil pointer dereference
2019-10-26T15:25:37.645-0700 [DEBUG] plugin.terraform-provider-vra: [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x1c12c4d]
2019-10-26T15:25:37.645-0700 [DEBUG] plugin.terraform-provider-vra:
2019-10-26T15:25:37.645-0700 [DEBUG] plugin.terraform-provider-vra: goroutine 46 [running]:
2019-10-26T15:25:37.645-0700 [DEBUG] plugin.terraform-provider-vra: github.com/vmware/terraform-provider-vra/vra.dataSourceRegionEnumerationRead(0xc000249d50, 0x1ce9060, 0xc0008b4600, 0xc000249d50, 0x0)
2019-10-26T15:25:37.645-0700 [DEBUG] plugin.terraform-provider-vra: 	/Users/mark/github/vmware/terraform-provider-vra/vra/data_source_region_enumeration.go:55 +0x37d

Error returned from POST /iaas/api/cloud-accounts-vsphere/region-enumeration

{"message":"The connection with cloud proxy is lost. Please make sure the agent is running in the cloud proxy virtual appliance or restart the agent if problem persists.","statusCode":404,"errorCode":0,"serverErrorId":"3a7cfcf8-edd2-4618-a39a-e35940a11f04","documentKind":"com:vmware:xenon:common:ServiceErrorResponse"}

I am trying the use case wherein I provision a vra_block_device first. And follow up with provisoning a vra_machine and attach the provisioned vra_block_device to it.

Iteration 1: provision vra_block_device

provider "vra" {
url = var.url
refresh_token = var.refresh_token
insecure = var.insecure
}

data "vra_project" "this" {
name = "e2e-terraform-vra-prithvish"
}

resource "vra_block_device" "disk1" {
capacity_in_gb = 10
name = "terraform_vra_block_device_1"
project_id = data.vra_project.this.id
}

Iteration 2: provision a machine and attach the provisioned disk in 1) to it

provider "vra" {
url = var.url
refresh_token = var.refresh_token
insecure = var.insecure
}

data "vra_project" "this" {
name = "e2e-terraform-vra-prithvish"
}

resource "vra_machine" "vms" {
count = var.instance_count
description = "terraform vra_machine"
project_id = data.vra_project.this.id
name = "tf-prithvish-machine-with-disk"
image = "ubuntu"
flavor = "small"
tags {
key = "foo"
value = "bar"
}
tags {
key = "OS"
value = "Ubuntu"
}
disks {
block_device_id = data.vra_block_device.this.id
}

timeouts {
create = "20m"
}
}

data "vra_block_device" "this" {
name = "terraform_vra_block_device1"
}

I get the following error when I do terraform apply

Error: Invalid data source

on main.tf line 35, in data "vra_block_device" "this":
35: data "vra_block_device" "this" {

The provider provider.vra does not support data source "vra_block_device".

NOTE: As a workaround I am able to hardcode block_device_id in the Iteration 2

Provisioning the resource used to create a deployment object with the same name as supplied as resource name but it doesn't create a deployment object anymore. Has this behavior changed?

Here is the main.tf file I am using

provider "vra" {
url = var.url
refresh_token = var.refresh_token
insecure = var.insecure
}

data "vra_project" "this" {
name = "e2e-terraform-vra-prithvish"
}

resource "vra_machine" "vms" {
count = var.instance_count
description = "terraform vra_machine"
project_id = data.vra_project.this.id
name = "tf-prithvish-machine"
image = "ubuntu"
flavor = "small"
tags {
key = "foo"
value = "bar"
}
tags {
key = "OS"
value = "Ubuntu"
}
timeouts {
create = "20m"
}
}

Provider talks to Cloud Assembly currently.
Customer has an XaaS service which is exposed in Service Broker.
Use Case: Customer wants invoke a REST operation on a 3rd party system and populated forms by dynamic values.
How can this be done through terraform provider?

Each resource creates a separate deployment in vRA which may be difficult to manage.

2019-07-22T14:29:54.499-0700 [DEBUG] plugin.terraform-provider-cas: 2019/07/22 14:29:54 POST /iaas/api/cloud-accounts-aws HTTP/1.1
2019-07-22T14:29:54.499-0700 [DEBUG] plugin.terraform-provider-cas: 2019/07/22 14:29:54 Host: api.staging.symphony-dev.com
2019-07-22T14:29:54.499-0700 [DEBUG] plugin.terraform-provider-cas: 2019/07/22 14:29:54 User-Agent: Go-http-client/1.1
2019-07-22T14:29:54.499-0700 [DEBUG] plugin.terraform-provider-cas: 2019/07/22 14:29:54 Content-Length: 214
2019-07-22T14:29:54.499-0700 [DEBUG] plugin.terraform-provider-cas: 2019/07/22 14:29:54 Accept: app/json
2019-07-22T14:29:54.499-0700 [DEBUG] plugin.terraform-provider-cas: 2019/07/22 14:29:54 Accept: application/json
2019-07-22T14:29:54.499-0700 [DEBUG] plugin.terraform-provider-cas: 2019/07/22 14:29:54 Authorization: Bearer
2019-07-22T14:29:54.499-0700 [DEBUG] plugin.terraform-provider-cas: 2019/07/22 14:29:54 Content-Type: application/json
2019-07-22T14:29:54.499-0700 [DEBUG] plugin.terraform-provider-cas: 2019/07/22 14:29:54 Accept-Encoding: gzip
2019-07-22T14:29:54.499-0700 [DEBUG] plugin.terraform-provider-cas: 2019/07/22 14:29:54
2019-07-22T14:29:54.499-0700 [DEBUG] plugin.terraform-provider-cas: 2019/07/22 14:29:54 {"accessKeyId":"----xxxxxxxxxxxxxxx-----","description":"created via cas terraform plugin","name":"aws-e2e","regionIds":["us-east-1","us-west-2"],"secretAccessKey":"----xxxxxxxxxxxxxxx-----","tags":[]}

2019-07-22T14:29:54.579-0700 [DEBUG] plugin.terraform-provider-cas: 2019/07/22 14:29:54 HTTP/1.1 500 Internal Server Error
2019-07-22T14:29:54.579-0700 [DEBUG] plugin.terraform-provider-cas: 2019/07/22 14:29:54 Content-Length: 229
2019-07-22T14:29:54.579-0700 [DEBUG] plugin.terraform-provider-cas: 2019/07/22 14:29:54 Access-Control-Expose-Headers: x-content-type-options,connection,content-length,referrer-policy,x-frame-options,x-xss-protection
2019-07-22T14:29:54.579-0700 [DEBUG] plugin.terraform-provider-cas: 2019/07/22 14:29:54 Cache-Control: no-cache, no-store, max-age=0, must-revalidate
2019-07-22T14:29:54.579-0700 [DEBUG] plugin.terraform-provider-cas: 2019/07/22 14:29:54 Connection: keep-alive
2019-07-22T14:29:54.579-0700 [DEBUG] plugin.terraform-provider-cas: 2019/07/22 14:29:54 Content-Type: application/json;charset=UTF-8
2019-07-22T14:29:54.579-0700 [DEBUG] plugin.terraform-provider-cas: 2019/07/22 14:29:54 Date: Mon, 22 Jul 2019 21:29:54 GMT
2019-07-22T14:29:54.579-0700 [DEBUG] plugin.terraform-provider-cas: 2019/07/22 14:29:54 Expires: 0
2019-07-22T14:29:54.579-0700 [DEBUG] plugin.terraform-provider-cas: 2019/07/22 14:29:54 Pragma: no-cache
2019-07-22T14:29:54.579-0700 [DEBUG] plugin.terraform-provider-cas: 2019/07/22 14:29:54 Referrer-Policy: no-referrer
2019-07-22T14:29:54.579-0700 [DEBUG] plugin.terraform-provider-cas: 2019/07/22 14:29:54 Strict-Transport-Security: max-age=31536000; includeSubDomains
2019-07-22T14:29:54.579-0700 [DEBUG] plugin.terraform-provider-cas: 2019/07/22 14:29:54 X-Content-Type-Options: nosniff
2019-07-22T14:29:54.579-0700 [DEBUG] plugin.terraform-provider-cas: 2019/07/22 14:29:54 X-Frame-Options: SAMEORIGIN
2019-07-22T14:29:54.579-0700 [DEBUG] plugin.terraform-provider-cas: 2019/07/22 14:29:54 X-Xss-Protection: 1 ; mode=block
2019-07-22T14:29:54.579-0700 [DEBUG] plugin.terraform-provider-cas: 2019/07/22 14:29:54
2019-07-22T14:29:54.579-0700 [DEBUG] plugin.terraform-provider-cas: 2019/07/22 14:29:54 {"timestamp":1563830994539,"path":"/iaas/api/cloud-accounts-aws","status":500,"error":"Internal Server Error","message":"Bearer token is malformed","@type":"org.springframework.security.oauth2.core.OAuth2AuthenticationException"}

Trying to do a vra_deployment.

Get a 500 error. This is a vra 8.0 instance

Here is my resource

resource "vra_deployment" "this" {
name = "${var.deployment_name}"
description = "terraform test deployment"

blueprint_id = "${var.blueprint_id}"
blueprint_version = "${var.blueprint_version}"
project_id = "${data.vra_project.this.id}"

inputs = {
vmName = "${var.deployment_name}"
inFlavor = "c5.large"
inTenant = "A"
inRail = "protected"
inlicense = "Redhat"
inCMI = "Cloud-init"
}

expand_resources = true
expand_last_request = true
}

Offering users pre-compiled, cross-platform downloads of the provider published as immutable GitHub releases would be very useful.

I recognize that terraform-provider-vra is still under early-stage development and perhaps pre-compiled releases aren't yet viewed as warranted. Nonetheless, as a potential user testing the provider functionality, in my mind, this could...

• save me from having to compile the terraform-provider-vra from source code
• reduce the possibility that one user is using a terraform-provider-vra compiled from source code that differs from the source code used to compile a different user's terraform-provider-vra
• help developers and users better understand the state of bugs and features

The terraform-provider-vinyldns releases here offer an example of what I'm imagining.

Thanks!

When modifying to attach an existing disk to a VM it does not attach.

  + disks {
      + block_device_id = "7f925b8589d8167559634b05ce105"
      + name            = "disk2"
    }

    nics {
        addresses          = []
        custom_properties  = {}
        device_index       = 0
        network_id         = "7f925b8589d816755962818e4c3a9"
        security_group_ids = []
    }

    tags {
        key   = "OS"
        value = "Windows"
    }

    timeouts {
        create = "20m"
        delete = "20m"
        update = "20m"
    }
}

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

vra_machine.vms[0]: Modifying... [id=9f28f11f75e2a2cf]
vra_machine.vms[0]: Modifications complete after 3s [id=9f28f11f75e2a2cf]

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

When running a vra_blueprint you can only do a deployment.
In vra it allows you to update a deployment which does an update operation

Example:

I have 3 machines in the blueprint and remove one and re-run terraform apply it says deployment name already exists. In vra you can run an update deployment and it would remove the vm.

2019/11/11 10:44:47 [TRACE] statemgr.Filesystem: writing snapshot at terraform.tfstate

2019/11/11 10:44:47 [TRACE] statemgr.Filesystem: removing lock metadata file .terraform.tfstate.lock.info
Error: a deployment with name 'tf1' exists already. Try with a differnet name

on main.tf line 16, in resource "vra_deployment" "this":
16: resource "vra_deployment" "this" {

We should support terraform import command for all types starting with machine, disk ,network objects

Looks like the URL is not using the full URL and is using only the host attribute. In our case we are proxying terraform before it hits vra.

So when we use URL when i run directly against vra using below
url = "https://vrahost.com/api/terraformassist/v1/vRA/region1/az1/sadf-adsfd-asdf-asdf"
this should fail but doesnt since it just uses the https://vrahost.com part.

This is more of a question. Is there a way in vra_machine to pass cloud init info?
In blueprints cloudinit can be passed, not sure if i have seen a way to pass cloud init via the terraform provider.

We are using cloud init to name machines, set ip address instead of using customization specs since only one or the other can be used. Also we are allowing users to use their own cloud init files to run after their VMs are created.

There does not appear to be a data source for Storage profiles. Is there an alternate name in use to apply storage profiles to machine disks?

Looks like in the newer verison vra_machine (iaas api) is submitting in batches of 10. It then waits for the 10 to complete before submitting the next batch.

Not sure if this is expected behavior, but if it is we should have a parameter to change batch size.
It took me 2.5 hours to provision 100 VMs today.

This is vra 8 on-prem and verified on vra 8 and vra 8.0.1 RC

When we provision using vra_deployment resource, we are taking blueprint_id & blueprint _version as input but we will like to use datasource for blueprint the same way we have for vra_project so we can pass the ID and version of blueprint to vra_deployment. We will also need similar datasource for catalog_item too

provider "vra" {
url = var.url
refresh_token = var.refresh_token
insecure = var.insecure
}
data "vra_project" "this" {
name = "TF-vRA-Provider Project"
}
resource "vra_deployment" "this" {
name = var.deployment_name
description = "Created for Terraform Demo."
blueprint_id = var.blueprint_id
blueprint_version = var.blueprint_version
project_id = data.vra_project.this.id
inputs = {
name = "PERMANENT"
}
expand_resources = true
timeouts {
create = "20m"
}
}

I provisioned 1 vra_machine & 2 vra_block_device with disks attached to machine.

This is the partial snippet of the state file after provisioning for the machine

{
"mode": "managed",
"type": "vra_machine",
"name": "vms_with_disk",
"provider": "provider.vra",
"instances": [
{
"schema_version": 0,
"attributes": {
"address": "10.196.156.43",
"boot_config": [],
"constraints": [],
"created_at": "2020-01-02",
"custom_properties": {
"cpuCount": "2",
"datastoreName": "vsanDatastore_cluster01",
"flavorProfileId": "d16f00ca-2d0b-4f75-be5a-116afdc0339e-98e8d62a-7b93-4b43-8659-4e4029bc6d1d",
"image": "ubuntu",
"imageProfileId": "d16f00ca-2d0b-4f75-be5a-116afdc0339e-98e8d62a-7b93-4b43-8659-4e4029bc6d1d",
"memoryGB": "9",
"memoryInMB": "10000",
"osType": "LINUX",
"ova.uri": "https://cloud-images.ubuntu.com/releases/16.04/release-20190605/ubuntu-16.04-server-cloudimg-amd64.ova",
"provisionGB": "10",
"softwareName": "Ubuntu Linux (64-bit)",
"vcUuid": "4c676f09-3926-4ac4-88fc-d66cef36f1b6"
},
"deployment_id": "afd52a26-f399-446f-bb62-6f9237f6da59",
"description": "terraform vra_machine",
"disks": [
{
"block_device_id": "44f8975e-04e5-458b-a368-0f78f1e6629c",
"description": "",
"name": ""
},
{
"block_device_id": "d77648bb-3ce0-4ded-95c2-8d34fd830fdb",
"description": "",
"name": ""
}
],
"external_id": "5001a4ab-7714-a87f-3427-b8d8eac37745",
"external_region_id": "Datacenter:datacenter-2",
"external_zone_id": "",
"flavor": "small",
"id": "152dde24-cd04-4abf-9858-f60244931cbe",
"image": null,
"image_disk_constraints": [],
"image_ref": null,

After running terraform import vra_machine.vms_with_disk <machine_id> inside another module, I noticed that the state file is missing the disk attribute for the given machine.

Here is the partial snippet of imported machine

"resources": [
{
"mode": "managed",
"type": "vra_machine",
"name": "vms_with_disk",
"provider": "provider.vra",
"instances": [
{
"schema_version": 0,
"attributes": {
"address": "10.196.156.43",
"boot_config": [],
"constraints": [],
"created_at": "2020-01-02",
"custom_properties": {
"cpuCount": "2",
"datastoreName": "vsanDatastore_cluster01",
"flavorProfileId": "d16f00ca-2d0b-4f75-be5a-116afdc0339e-98e8d62a-7b93-4b43-8659-4e4029bc6d1d",
"image": "ubuntu",
"imageProfileId": "d16f00ca-2d0b-4f75-be5a-116afdc0339e-98e8d62a-7b93-4b43-8659-4e4029bc6d1d",
"memoryGB": "9",
"memoryInMB": "10000",
"osType": "LINUX",
"ova.uri": "https://cloud-images.ubuntu.com/releases/16.04/release-20190605/ubuntu-16.04-server-cloudimg-amd64.ova",
"provisionGB": "10",
"softwareName": "Ubuntu Linux (64-bit)",
"vcUuid": "4c676f09-3926-4ac4-88fc-d66cef36f1b6"
},
"deployment_id": "afd52a26-f399-446f-bb62-6f9237f6da59",
"description": "terraform vra_machine",
"disks": [],
"external_id": "5001a4ab-7714-a87f-3427-b8d8eac37745",
"external_region_id": "Datacenter:datacenter-2",
"external_zone_id": "",
"flavor": null,
"id": "152dde24-cd04-4abf-9858-f60244931cbe",
"image": null,
"image_disk_constraints": [],
"image_ref": null,

I am trying the usecase where I import the machine and perform detach disk action one of the disks using terraform apply, however the plan doesn't detect the detach disk change

Tag update is not supported. It could be either new tags or updating existing tags (keys) with a different value

Changing the image attribute should recreate the machine

Changing the disk size should update the disk

I have added a second disk to a machine.
Remove the disk from the terraform file and run terraform apply.

boot_config {
content = " runcmd:\n - New-Item -Path "C:\temp\" -Name "logfiles" -ItemType
"directory"\n"
}

  - disks {
      - block_device_id = "7f925b8589d816755962b18f7a420" -> null
      - name            = "disk2" -> null
    }

  nics {
        addresses          = []
        custom_properties  = {}
        device_index       = 0
        network_id         = "7f925b8589d816755962818e4c3a9"
        security_group_ids = []
    }

    tags {
        key   = "OS"
        value = "Windows"
    }

    timeouts {
        create = "20m"
        delete = "20m"
        update = "20m"
    }
}

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

vra_machine.vms[0]: Modifying... [id=bd38273dc820eecf]
vra_machine.vms[0]: Modifications complete after 3s [id=bd38273dc820eecf]

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

The disk is still attached to the VM and not removing it.

Following up after the workaround in #123

I did terraform apply for the following main.tf file and was able to provision a machine and attach the pre-created disk to it.

In the second iteration I did terraform destroy and the machine as well as the attached disk. However, it was expected that it will only detach the disk and delete the machine.

provider "vra" {
url = var.url
refresh_token = var.refresh_token
insecure = var.insecure
}

data "vra_project" "this" {
name = "e2e-terraform-vra-prithvish"
}

resource "vra_machine" "vms" {
count = var.instance_count
description = "terraform vra_machine"
project_id = data.vra_project.this.id
name = "tf-prithvish-machine-with-disk"
image = "ubuntu"
flavor = "small"
tags {
key = "foo"
value = "bar"
}
tags {
key = "OS"
value = "Ubuntu"
}
disks {
block_device_id = "5c1dfebfc275ba75599394155c558"
}

timeouts {
create = "20m"
}
}

Iteration 1: Provisioning machines and disk (attached to machine as well as stand alone)

provider "vra" {
url = var.url
refresh_token = var.refresh_token
insecure = var.insecure
}

data "vra_project" "this" {
name = "e2e-terraform-vra-prithvish"
}

resource "vra_machine" "vms" {
count = var.instance_count
description = "terraform vra_machine"
project_id = data.vra_project.this.id
name = "Terraform_Provider-003"
image = "ubuntu"
flavor = "small"
tags {
key = "foo"
value = "bar"
}
tags {
key = "OS"
value = "Ubuntu"
}
disks {
block_device_id = vra_block_device.disk3[0].id
}

timeouts {
create = "20m"
}
}

resource "vra_block_device" "disk3" {
capacity_in_gb = 10
count = 2
name = "terraform_vra_block_device_103"
project_id = data.vra_project.this.id
}

resource "vra_block_device" "disk1" {
capacity_in_gb =10
name = "terraform_vra_block_device_104"
project_id = data.vra_project.this.id
}

Iteration 2: Resize the standalone disk to 20GB

provider "vra" {
url = var.url
refresh_token = var.refresh_token
insecure = var.insecure
}

data "vra_project" "this" {
name = "e2e-terraform-vra-prithvish"
}

resource "vra_machine" "vms" {
count = var.instance_count
description = "terraform vra_machine"
project_id = data.vra_project.this.id
name = "Terraform_Provider-003"
image = "ubuntu"
flavor = "small"
tags {
key = "foo"
value = "bar"
}
tags {
key = "OS"
value = "Ubuntu"
}
disks {
block_device_id = vra_block_device.disk3[0].id
}

timeouts {
create = "20m"
}
}

resource "vra_block_device" "disk3" {
capacity_in_gb = 10
count = 2
name = "terraform_vra_block_device_103"
project_id = data.vra_project.this.id
}

resource "vra_block_device" "disk1" {
capacity_in_gb =20
name = "terraform_vra_block_device_104"
project_id = data.vra_project.this.id
}

Iteration 2 results in 500 internal Server error. Here are the debug logs

2019-12-10T00:48:49.055-0800 [DEBUG] plugin.terraform-provider-vra: 2019/12/10 00:48:49 0
2019-12-10T00:48:49.055-0800 [DEBUG] plugin.terraform-provider-vra: 2019/12/10 00:48:49
2019-12-10T00:48:49.055-0800 [DEBUG] plugin.terraform-provider-vra: 2019/12/10 00:48:49
2019-12-10T00:48:49.055-0800 [DEBUG] plugin.terraform-provider-vra: 2019/12/10 00:48:49
2019-12-10T00:48:49.056-0800 [DEBUG] plugin.terraform-provider-vra: 2019/12/10 00:48:49 GET /deployment/api/deployments//resources//actions HTTP/1.1
2019-12-10T00:48:49.056-0800 [DEBUG] plugin.terraform-provider-vra: 2019/12/10 00:48:49 Host: cmbu-mario.eng.vmware.com
2019-12-10T00:48:49.056-0800 [DEBUG] plugin.terraform-provider-vra: 2019/12/10 00:48:49 User-Agent: Go-http-client/1.1
2019-12-10T00:48:49.056-0800 [DEBUG] plugin.terraform-provider-vra: 2019/12/10 00:48:49 Accept: application/json
2019-12-10T00:48:49.056-0800 [DEBUG] plugin.terraform-provider-vra: 2019/12/10 00:48:49 Authorization: Bearer xxxxxxxxxxxxxxxxxxxxxxxx........xxxxxxxxxxxxx
2019-12-10T00:48:49.056-0800 [DEBUG] plugin.terraform-provider-vra: 2019/12/10 00:48:49 Accept-Encoding: gzip
2019-12-10T00:48:49.056-0800 [DEBUG] plugin.terraform-provider-vra: 2019/12/10 00:48:49
2019-12-10T00:48:49.056-0800 [DEBUG] plugin.terraform-provider-vra: 2019/12/10 00:48:49
2019-12-10T00:48:49.056-0800 [DEBUG] plugin.terraform-provider-vra: 2019/12/10 00:48:49
2019-12-10T00:48:49.199-0800 [DEBUG] plugin.terraform-provider-vra: 2019/12/10 00:48:49 HTTP/1.1 500 Internal Server Error
2019-12-10T00:48:49.199-0800 [DEBUG] plugin.terraform-provider-vra: 2019/12/10 00:48:49 Content-Length: 219
2019-12-10T00:48:49.199-0800 [DEBUG] plugin.terraform-provider-vra: 2019/12/10 00:48:49 Content-Type: application/json;charset=UTF-8
2019-12-10T00:48:49.199-0800 [DEBUG] plugin.terraform-provider-vra: 2019/12/10 00:48:49 Date: Tue, 10 Dec 2019 08:48:39 GMT
2019-12-10T00:48:49.199-0800 [DEBUG] plugin.terraform-provider-vra: 2019/12/10 00:48:49
2019-12-10T00:48:49.199-0800 [DEBUG] plugin.terraform-provider-vra: 2019/12/10 00:48:49 {"timestamp":"2019-12-10T08:48:39.823+0000","status":500,"error":"Internal Server Error","message":"The request was rejected because the URL was not normalized.","path":"/deployment/api/deployments//resources//actions"}
2019-12-10T00:48:49.199-0800 [DEBUG] plugin.terraform-provider-vra: 2019/12/10 00:48:49
2019/12/10 00:48:49 [DEBUG] vra_block_device.disk1: apply errored, but we're indicating that via the Error pointer rather than returning it: unknown error (status 500): {resp:0xc0004d2480}
2019/12/10 00:48:49 [TRACE] : eval: *terraform.EvalMaybeTainted
2019/12/10 00:48:49 [TRACE] : eval: *terraform.EvalWriteState
2019/12/10 00:48:49 [TRACE] EvalWriteState: recording 0 dependencies for vra_block_device.disk1
2019/12/10 00:48:49 [TRACE] EvalWriteState: writing current state object for vra_block_device.disk1

Error: unknown error (status 500): {resp:0xc0004d2480}

on main.tf line 91, in resource "vra_block_device" "disk1":
91: resource "vra_block_device" "disk1" {

When persistent= true for a vra_block_device, then when removing the vm during terraform update action, then the disk should not be deleted even though the vm is gone.

I created a machine that is attached to disk using

provider "vra" {
url = var.url
refresh_token = var.refresh_token
insecure = var.insecure
}

data "vra_project" "this" {
name = "e2e-terraform-vra-prithvish"
}

resource "vra_machine" "vms" {
count = var.instance_count
description = "terraform vra_machine"
project_id = data.vra_project.this.id
name = "Terraform_Provider-002"
image = "centos"
flavor = "small"
tags {
key = "foo"
value = "bar"
}
tags {
key = "OS"
value = "Ubuntu"
}
disks {
block_device_id = vra_block_device.disk3[1].id
}

timeouts {
create = "20m"
}
}

resource "vra_block_device" "disk3" {
capacity_in_gb = 10
count = 2
name = "terraform_vra_block_device_102"
project_id = data.vra_project.this.id
}

In the second iteration, I changed the image to ubuntu

provider "vra" {
url = var.url
refresh_token = var.refresh_token
insecure = var.insecure
}

data "vra_project" "this" {
name = "e2e-terraform-vra-prithvish"
}

resource "vra_machine" "vms" {
count = var.instance_count
description = "terraform vra_machine"
project_id = data.vra_project.this.id
name = "Terraform_Provider-002"
image = "ubuntu"
flavor = "small"
tags {
key = "foo"
value = "bar"
}
tags {
key = "OS"
value = "Ubuntu"
}
disks {
block_device_id = vra_block_device.disk3[1].id
}

timeouts {
create = "20m"
}
}

resource "vra_block_device" "disk3" {
capacity_in_gb = 10
count = 2
name = "terraform_vra_block_device_102"
project_id = data.vra_project.this.id
}

The second iteration fails with 404.
I think when it tries to recreate a machine, the disk gets deleted when machine is deleted and the newly recreated machine is look for the disk to attach to

There does not appear to be a data source for network profiles. Is there an alternate name in use to apply network profiles to a machine resource?

When using vRA image maps for the machine resource, we are finding that any cloud-config attached to the image (not in the terraform yaml) is being ignored, i.e. not executed. This seems to be true for cloud-init and cloudbase-init.

If i delete a device with block compute attached, keeps throwing my tfstate file off.

vra_machine.vms[0]: Destroying... [id=733e9e938e3d66cf]
vra_machine.vms[0]: Still destroying... [id=733e9e938e3d66cf, 10s elapsed]
vra_machine.vms[0]: Still destroying... [id=733e9e938e3d66cf, 20s elapsed]
vra_machine.vms[0]: Destruction complete after 20s
vra_block_device.vms: Destroying... [id=7f925b8589d8167559621948975c9]

Error: unknown error (status 204): {resp:0xc0000e42d0}

HQSML-1712491:bin mdittb638$ terraform destroy
data.vra_project.this: Refreshing state...
data.vra_cloud_account_vsphere.this: Refreshing state...
data.vra_network.this: Refreshing state...
vra_block_device.vms: Refreshing state... [id=7f925b8589d8167559621948975c9]

Error: unknown error (status 404): {resp:0xc0001babd0}

HQSML-1712491:bin mdittb638$ terraform destroy
data.vra_project.this: Refreshing state...
data.vra_cloud_account_vsphere.this: Refreshing state...
data.vra_network.this: Refreshing state...
vra_block_device.vms: Refreshing state... [id=7f925b8589d8167559621948975c9]

Error: unknown error (status 404): {resp:0xc0000f8480}

HQSML-1712491:bin mdittb638$ terraform apply
data.vra_project.this: Refreshing state...
data.vra_cloud_account_vsphere.this: Refreshing state...
data.vra_network.this: Refreshing state...
vra_block_device.vms: Refreshing state... [id=7f925b8589d8167559621948975c9]

Error: unknown error (status 404): {resp:0xc0000dc3f0}

Only way to start working with terraform is to get rid of tfstate file and copy from backupfile.

Terraform is below

resource "vra_block_device" "vms" {
capacity_in_gb = 500
name = "terraform_vra_block_device"
project_id = data.vra_project.this.id
}

resource "vra_machine" "vms" {
count = "${var.instance_count}"
description = "terrafrom test machine"
project_id = data.vra_project.this.id
image = "Cloudbase-init"
flavor = "c5.large"
name = "tf-q1-${count.index}"
nics {
network_id = data.vra_network.this.id
}
disks {
block_device_id = vra_block_device.vms.id
name = "disk2"
}
depends_on = [vra_block_device.vms]
}

Observing issue for vRACloud Assembly provider.
Using : terraform-provider-vra-linux_amd64-v0.1.6.tgz

When count = 2 (more than 1), getting below error :
Error: [GET /deployment/api/deployments/{depId}][404] getDeploymentByIdUsingGETNotFound

Snippet :
provider "vra" {
url = "https://vra_domain"
refresh_token = "XXXXXXXXXXXXXXX"
insecure = true
}

data "vra_project" "this" {
name = "TEST"
}
resource "vra_deployment" "this" {
count = 2
name = "Test Blueprint Deployment"
description = "terraform test deployment"

blueprint_id = "xxxxx-xxxxx-xxxx-xxxx"
blueprint_version = ""
project_id = data.vra_project.this.id

inputs = {
flavor = "small"
image = "centos"
count = 2
flag = true
}

timeouts {
create = "60m"
delete = "2h"
}

expand_resources = true
expand_last_request = true
}

Output with Error:
vra_deployment.this[1]: Creating...
vra_deployment.this[0]: Creating...
vra_deployment.this[1]: Still creating... [10s elapsed]
vra_deployment.this[1]: Still creating... [20s elapsed]
........
.......
vra_deployment.this[1]: Still creating... [15m0s elapsed]
vra_deployment.this[1]: Still creating... [15m10s elapsed]
vra_deployment.this[1]: Still creating... [15m20s elapsed]
vra_deployment.this[1]: Creation complete after 15m23s [id=xxxxxx-xxxx-xxxx-xxxxxx]

Error: [GET /deployment/api/deployments/{depId}][404] getDeploymentByIdUsingGETNotFound

on vra_blueprint.tf line 12, in resource "vra_deployment" "this":
12: resource "vra_deployment" "this" {

Where as, it successfully runs with count=1

When using the example file that is available here I am unable to successfully enumerate the regions. vCenter.

Hard coding the regions works, but it does not work with the data object.

Worked with @dmettem to troubleshoot this issue.

Log File:
terraform.log

When trying to apply a plan to a vRA8 endpoint ( vRA 8 On-Prem)
I get the error

Error: Post https://cava-n-89-120.eng.vmware.com/iaas/api/login: x509: certificate signed by unknown authority

on main.tf line 1, in provider "vra":
1: provider "vra" {

Tried introducing variable : ignore_cert_warning = "true"
but it doesn't seem to be supported....

==============
Error: Unsupported argument

on main.tf line 4, in provider "vra":
4: ignore_cert_warning = "true"

Any workaround?

When running as a count we are getting a 404 for some of the machines being built. In the case below I had a count of 7 machines. 2 of the machines errored with a Service not found: 404 NOT_FOUND " No matching handler"

2019/10/24 12:52:32 [DEBUG] vra_machine.vms[4]: apply errored, but we're indicating that via the Error pointer rather than returning it: com.vmware.xenon.common.ServiceHost$ServiceNotFoundException: Service not found: 404 NOT_FOUND "No matching handler"
2019/10/24 12:52:32 [TRACE] : eval: *terraform.EvalMaybeTainted
2019/10/24 12:52:32 [TRACE] EvalMaybeTainted: vra_machine.vms[4] encountered an error during creation, so it is now marked as tainted
2019/10/24 12:52:32 [TRACE] : eval: *terraform.EvalWriteState
2019/10/24 12:52:32 [TRACE] EvalWriteState: removing state object for vra_machine.vms[4]
2019/10/24 12:52:32 [TRACE] : eval: *terraform.EvalApplyProvisioners
2019/10/24 12:52:32 [TRACE] EvalApplyProvisioners: vra_machine.vms[4] has no state, so skipping provisioners
2019/10/24 12:52:32 [TRACE] : eval: *terraform.EvalMaybeTainted
2019/10/24 12:52:32 [TRACE] EvalMaybeTainted: vra_machine.vms[4] encountered an error during creation, so it is now marked as tainted
2019/10/24 12:52:32 [TRACE] : eval: *terraform.EvalWriteState
2019/10/24 12:52:32 [TRACE] EvalWriteState: removing state object for vra_machine.vms[4]
2019/10/24 12:52:32 [TRACE] : eval: *terraform.EvalIf
2019/10/24 12:52:32 [TRACE] : eval: *terraform.EvalIf
2019/10/24 12:52:32 [TRACE] : eval: *terraform.EvalWriteDiff
2019/10/24 12:52:32 [TRACE] : eval: *terraform.EvalApplyPost
2019/10/24 12:52:32 [ERROR] : eval: *terraform.EvalApplyPost, err: com.vmware.xenon.common.ServiceHost$ServiceNotFoundException: Service not found: 404 NOT_FOUND "No matching handler"
2019/10/24 12:52:32 [ERROR] : eval: *terraform.EvalSequence, err: com.vmware.xenon.common.ServiceHost$ServiceNotFoundException: Service not found: 404 NOT_FOUND "No matching handler"
2019/10/24 12:52:32 [TRACE] [walkApply] Exiting eval tree: vra_machine.vms[4]
2019/10/24 12:52:32 [TRACE] vertex "vra_machine.vms[4]": visit complete
2019/10/24 12:52:32 [DEBUG] vra_machine.vms[2]: apply errored, but we're indicating that via the Error pointer rather than returning it: com.vmware.xenon.common.ServiceHost$ServiceNotFoundException: Service not found: 404 NOT_FOUND "No matching handler"
2019/10/24 12:52:32 [TRACE] : eval: *terraform.EvalMaybeTainted
2019/10/24 12:52:32 [TRACE] EvalMaybeTainted: vra_machine.vms[2] encountered an error during creation, so it is now marked as tainted
2019/10/24 12:52:32 [TRACE] : eval: *terraform.EvalWriteState
2019/10/24 12:52:32 [TRACE] EvalWriteState: removing state object for vra_machine.vms[2]
2019/10/24 12:52:32 [TRACE] : eval: *terraform.EvalApplyProvisioners
2019/10/24 12:52:32 [TRACE] EvalApplyProvisioners: vra_machine.vms[2] has no state, so skipping provisioners
2019/10/24 12:52:32 [TRACE] : eval: *terraform.EvalMaybeTainted
2019/10/24 12:52:32 [TRACE] EvalMaybeTainted: vra_machine.vms[2] encountered an error during creation, so it is now marked as tainted
2019/10/24 12:52:32 [TRACE] : eval: *terraform.EvalWriteState
2019/10/24 12:52:32 [TRACE] EvalWriteState: removing state object for vra_machine.vms[2]
2019/10/24 12:52:32 [TRACE] : eval: *terraform.EvalIf
2019/10/24 12:52:32 [TRACE] : eval: *terraform.EvalIf
2019/10/24 12:52:32 [TRACE] : eval: *terraform.EvalWriteDiff
2019/10/24 12:52:32 [TRACE] : eval: *terraform.EvalApplyPost
2019/10/24 12:52:32 [ERROR] : eval: *terraform.EvalApplyPost, err: com.vmware.xenon.common.ServiceHost$ServiceNotFoundException: Service not found: 404 NOT_FOUND "No matching handler"
2019/10/24 12:52:32 [ERROR] : eval: *terraform.EvalSequence, err: com.vmware.xenon.common.ServiceHost$ServiceNotFoundException: Service not found: 404 NOT_FOUND "No matching handler"
2019/10/24 12:52:32 [TRACE] [walkApply] Exiting eval tree: vra_machine.vms[2]
2019/10/24 12:52:32 [TRACE] vertex "vra_machine.vms[2]": visit complete

The API called to get the projects may not be using the queryparams/filter while making the API call. Instead it appears to be fetching all projects and then applying the filter. This breaks if I have more than 500 projects as the project that is being searched for is not present in the 500 returned projects