Giter Club home page Giter Club logo

vmware / terraform-provider-vra7 Goto Github PK

View Code? Open in Web Editor NEW
39.0 19.0 38.0 11.45 MB

Terraform VMware vRealize Automation 7 provider - VMware has ended the active development of this Terraform Provider, so this repository will no longer be updated.

Home Page: https://registry.terraform.io/providers/vmware/vra7/latest

License: Mozilla Public License 2.0

Makefile 1.12% HCL 1.60% Go 95.67% Shell 1.17% HTML 0.44%
terraform-provider vra7 terraform vmware vmware-vrealize-automation archived

terraform-provider-vra7's Introduction

Terraform provider for VMware vRealize Automation 7

NOTE: The End of General Support for VMware vRealize Suite7.x (which includes vRA 7.x, vRops 7.x and vRLI 7.x) was on September 1st, 2022. Therefore, VMware has ended the active development of this Terraform Provider, so this repository will no longer be updated. We recommend users migrate to the VMware vRealize Automation v8 Provider.

Introduction

A self-contained deployable integration between Terraform and vRealize Automation (vRA) which allows Terraform users to request/provision entitled vRA catalog items using Terraform. Supports Terraform destroying vRA provisioned resources.

Requirements

Using the provider

See the vra7 documentation to get started using the vRealize Automation 7 provider.

See vra7_deployment resource examples [here] (examples/README.md)

Execution

These are the Terraform commands that can be used for the vRA plugin:

  • terraform init - The init command is used to initialize a working directory containing Terraform configuration files.
  • terraform plan - Plan command shows plan for resources like how many resources will be provisioned and how many will be destroyed.
  • terraform apply - apply is responsible to execute actual calls to provision resources.
  • terraform refresh - By using the refresh command you can check the status of the request.
  • terraform show - show will set a console output for resource configuration and request status.
  • terraform destroy - destroy command will destroy all the resources present in terraform configuration file.

Navigate to the location where main.tf and binary are placed and use the above commands as needed.

Upgrading the provider

The vra7 provider doesn't upgrade automatically once you've started using it. After a new release you can run

terraform init -upgrade

to upgrade to the latest stable version of the vra7 provider. See the Terraform website for more information on provider upgrades, and how to set version constraints on your provider.

A sample main.tf file is as follows:

provider "vra7" {
  username = var.username
  password = var.password
  tenant   = var.tenant
  host     = var.host
}

resource "vra7_deployment" "this" {
    count                      = 1
    catalog_item_name          = "multi_machine_catalog"
    businessgroup_name         = Development
    wait_timeout               = 20
    lease_days                 = 15                           //number of lease days

    deployment_configuration = {
        "BPCustomProp"               = "custom depl prop"     //custom property in BP required while requesting a catalog item
        "Container"                  = "App.Container"        //property of a property group
        "Container.Auth.User"        = "var.container_user"   //property of a property group
        "Container.Auth.Password"    = "var.container_pw"     //property of a property group
        "Container.Connection.Port"  = "var.container_port"   //property of a property group
        "businessGroups" = <<EOF                              //this is an example to property of type array of strings
        [
            "bgTest1",
            "bgTest2"
        ]
        EOF
    }

    resource_configuration {
        component_name              = "Windows"       //This is the component name and need not be prefixed with all properties
        cluster                     = 2               //cluster is added as a property in the schema. Modifying it will do the
                                                      // Scale In/Out Day 2 actions
        configuration = {
            cpu                     = 2
            memory                  = 1024
            vm_custom_prop          = "a custom prop"
        }
    }

    resource_configuration {
        component_name              = "Linux"      //This is the component name and need not be prefixed with all properties
        configuration = {
            cpu                     = 2
            security_tag = <<EOF                   //this is an example to property of type array of strings
            [
                "dev_sg",
                "prod_sg"
            ]
            EOF
        }
    }

    resource_configuration {
        component_name              = "http"      //This is the component name and need not be prefixed with all properties
        configuration = {
            hostname                = "xyz.com"          //HTTP (apache) hostname
            network_mode            = "bridge"           //HTTP (apache) network mode
        }
    }
}

Supported Day 2 actions. Examples are provided in the documentation

  1. Change lease: To do this, add the new expiry_date in the config file.
  2. Scale: Change the cluster size
  3. Reconfigure: Modify/add properties inside the configuration block under resource_configuration block

Outputs

The resource_configuration block has an instances block that is a list of all the instances/VMs corresponding to a component. The instance list size is nothing but the custer size.

For example, after the deployment is created using the above config file, the resource_configuration list size will be 3. And the instances list size in the resource configuration map corresonding to the component "Windows" will be 2. This is because the cluster size is 2 and it creates 2 VMs with that configuration.

Sample outputs:

output "ip_address" {
    value = vra7_deployment.this[*].resource_configuration[*].instances[*].properties.ip_address
}
output "component" {
    value = vra7_deployment.this[*].resource_configuration[*].component_name
}
output "vm_name" {
    value = vra7_deployment.this[*].resource_configuration[*].instances[*].properties.name
}

Expected sample outputs (based on the above main.tf, ip_address and vm_names are mock data below):

ip_address = [
  [
    [
      "10.xxx.xxx.xxx",
      "10.xxx.xxx.xxx",
    ],
    [
      "10.xxx.xxx.xxx"
    ],
    [
      "10.xxx.xxx.xxx"
    ],
  ],
]


component = [
  [
    "Windows",
    "Linux",
    "http",
  ],
]

vm_name = [
  [
    [
      "Windows-machine1-2048",
      "Windows-machine2-2049",
    ],
    [
      "Linux-machine1-2050",
    ],
    [
      "http-machine1-2051",
    ],
  ],
]

Import vra7_deployment

Import functionality is now supported for the vra7_deployment resource. If there is an exiting deployment, it can be imported by catalog item request id.

main.tf

provider "vra7" {
  username = var.username
  password = var.password
  tenant   = var.tenant
  host     = var.host
}

resource vra7_deployment "this" {
    // the properties can be added once the import is completed by referring to the state file
}

terraform import vra7_deployment.this <request_id>

Data source vra7_deployment

A data source for vra7_deployment can also be created using either deployment ID or catalog item request id. Refer to the documentation here

Building the provider

Clone repository to: $GOPATH/src/github.com/vmware/terraform-provider-vra7

$ mkdir -p $GOPATH/src/github.com/terraform-providers; cd $GOPATH/src/github.com/terraform-providers
$ git clone [email protected]:terraform-providers/terraform-provider-vra7

Enter the provider directory and build the provider

$ cd $GOPATH/src/github.com/vmware/terraform-provider-vra7
$ make build

Developing the provider

If you wish to work on the provider, you'll first need Go installed on your machine (version 1.11.4+ is required). You'll also need to correctly setup a GOPATH, as well as adding $GOPATH/bin to your $PATH.

To compile the provider, run make build. This will build the provider and put the provider binary in the $GOPATH/bin directory.

$ make build
...
$ $GOPATH/bin/terraform-provider-vra7
...

Contributing

Terraform is the work of thousands of contributors. We appreciate your help!

To contribute, please read the contribution guidelines: Contributing to Terraform - vRealize Automation 7 Provider

Issues on GitHub are intended to be related to bugs or feature requests with provider codebase. See https://www.terraform.io/docs/extend/community/index.html for a list of community resources to ask questions about Terraform.

License

terraform-provider-vra7 is available under the Mozilla Public License, version 2.0 license.

terraform-provider-vra7's People

Contributors

bflad avatar bill-rich avatar cars avatar cgriggs01 avatar danacr avatar dusty73 avatar frodenas avatar harmjanblok avatar maciejkaras avatar markpeek avatar mbfrahry avatar michaelpak avatar nferro avatar prativa20 avatar roidelapluie avatar sky-philipalmeida avatar skylerto avatar swierq avatar tcorfmat avatar virajindasrao avatar vmwsrpbot avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

terraform-provider-vra7's Issues

Terraform crash : rpc error: code = Unavailable desc = transport is closing

vRA 7.x version
vRealize Automation 7.6

Terraform version
v0.12.24

terraform-provider-vra7 plugin version
The terraform-provider-vra7 plugin version 1.0.0

Describe the bug
Issue with latest provider, when deploying any blueprint, at the end, terraform crash with the following error

rpc error: code = Unavailable desc = transport is closing

Since terraform crash the tfstate is not saved and we can no longer manage this deployment, haven't test the import functionality yet, but nonetheless, this shouldn't be required

To Reproduce
Steps to reproduce the behavior:

  1. maint.tf content
provider "vra7" {
    username = var.vra_username
    password = var.vra_password
    tenant = var.vra_tenant
    host = var.vra_host
    insecure = true
}

resource "vra7_deployment" "deployment" {
  businessgroup_name = "dev"
  catalog_item_name = "dev vm"              
  reasons = "provide a reason"
  description = "provide a description"
  lease_days = 2

  resource_configuration {
    component_name = "vm1"
    cluster = 1

    //Please Provide the following information for the bootstrap node component
    configuration = {
      "custom.midname" = "BASE"
    }
  } 
}
  1. Terraform command
    terraform apply

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

Expected behavior
complete successfully

Logs
crash.log

vra-terraform.log

Desktop (please complete the following information):

  • OS: Windows 2016 and CentOS 7

Issue with Terraform PLAN

vRA 7.x version
7.4
Terraform version
v0.12.13
terraform-provider-vra7 plugin version
provider.vra7 v1.0.1

Describe the bug
I am able to deploy VMs using the latest official provider. Once the VMS are deployed, if I run a TF plan, the provider shows that the "resource_configuration" options need to be changed.

image

image

Expected behavior
Since the configuration has not been modified, the provider should not try to modify the config.
This creates a confusion, if there are new resources that need to be deployed.

Screenshots
If applicable, add screenshots to help explain your problem.

Read `resource_configuration` from non-VM Deployments

When we create deployment from a blueprint that contains vCenter VMs (resourceType == sdk.InfrastructureVirtual) then the provider reads the content[].data{} back from the deployment and puts it into resource_configuration blocks in the state file.

We still like to read back resource_configuration details also for XaaS software components, but for any non-VM deployments, this is not yet implemented.

There also seems to be a difference in how the vRA API responds when reading a Deployment. When VMs are part of the blueprint, they seem to be direct children of the deployment. They are directly listed within content[] of the resourceViews response together with the deployment itself. However, when there are XaaS components in the blueprint, they are not listed within content[] of the resourceViews response, only the deployment itself.

The non-VM components still can be retrieved via the GET: Child Resources link from the response, so the TF provider would be needed to be expanded with this.

description and reason are not being set

vRA 7.5
Terraform v0.13.3
registry.terraform.io/vmware/vra7 v2.0.0

Describe the bug
description and reasons are not being set on the deployment

To Reproduce
Steps to reproduce the behavior:

  1. Terraform config file
resource "vra7_deployment" "this" {
  catalog_item_id       = var.catalog_item_id
  reasons               = "some reason"
  description           = "some description"
  lease_days            = 100
}
  1. Terraform command
terraform init
terraform plan
  1. Error
    No errors

Expected behavior
description and reasons are set. During terraform plan I would expect to see the value being set instead of just reading (known after apply) like the lease_days. Anyway description is not being set even after apply, everything else work as expected.

Logs

Terraform will perform the following actions:

  # vra7_deployment.this will be created
  + resource "vra7_deployment" "this" {
      + businessgroup_id   = (known after apply)
      + businessgroup_name = (known after apply)
      + catalog_item_id    = "5f476c1c-426e-45da-b4ca-183625a39e1e"
      + date_created       = (known after apply)
      + deployment_destroy = true
      + deployment_id      = (known after apply)
      + description        = (known after apply)
      + id                 = (known after apply)
      + last_updated       = (known after apply)
      + lease_days         = 100
      + lease_end          = (known after apply)
      + lease_start        = (known after apply)
      + name               = (known after apply)
      + owners             = (known after apply)
      + reasons            = (known after apply)
      + request_status     = (known after apply)
      + tenant_id          = (known after apply)
      + wait_timeout       = 15

      + resource_configuration {
          + cluster            = (known after apply)
          + component_name     = (known after apply)
          + configuration      = (known after apply)
          + instances          = (known after apply)
          + ip_address         = (known after apply)
          + parent_resource_id = (known after apply)
          + request_id         = (known after apply)
          + request_state      = (known after apply)
        }
    }

Desktop (please complete the following information):

  • OS: Running in Docker image hashicorp/terraform:0.13.3

Import a deployment without a request id

vRA 7.x version
Version: 7.5.0 (Build: 10053500)
Terraform version
0.12
terraform-provider-vra7 plugin version
1.0.0

Describe the bug
An accident was made in vRA and everyone's deployments were removed from their business groups. This was fixed by re-registering all deployments back with the appropriate business groups but there is a side effect of losing all the requests. Because of this, anyone that used terraform in the past to deploy catalog items, can no longer use terraform to maintain them since the request ids are gone.

I was wondering if there is a way to import a vra7_deployment by using the deployment id instead of the request id.

Unneccesary lookup of BusinessGroupId via Identity API

terraform-provider-vra7 plugin version 3.0.0

The latest release now sets the "businessgroup_name" as party of resourceVrs7DeploymentRead - line 448 of resource_vra7_deployment.go

On line 637 of resource_vra7_deployment.go, a check is made to see if the name is provided and then the BusinessGroupId is looked up from the name. This involves a call to the identity API. Unfortunately for us, we do not have permission to access this particular api.

Given that the BusinessGroupId has already been provided and set, this is unnecessary. It would make sense to only lookup the BusinessGroupId if its not already set.

MODIFY resource interfaces does not work correctly.

vRA 7.x version
7.4
Terraform version
v0.12.13
terraform-provider-vra7 plugin version
provider.vra7 v0.5.0

Describe the bug
Modification of resource configuration objects like CPU and MEMORY works prefectly fine using the VRA provider.

When I try to modification of custom network profile names does not work. The provider state shows that the profile has been changed. However, on the VRA the interface profile remains unchanged.

To Reproduce
Steps to reproduce the behavior:

  1. Terraform config file
    Our environment has VMs with multiple nics, so the VRA has been configured to include multiple network groups which can then be added to VM nics as per requirement.
    This is how the resource configured, with "NETWOK0" nic assigned to "TEST_NET_01"

image

Resource state, once it's provisioned by VRA:

image

Now I want to test the modify feature and change the nic "NETWORK0" to be part of another net group "TEST_NET_05"

The resource config looks like this now :
image

The respective state file after modification looks like this ,

image

According to the provider, the resource has been modified, however, the VM configuration remains unchanged.
On checking VRA logs, we see that the provider does send a modify request to VRA, however, the request is empty or it does not specify the modification of the nic to be performed.
In case of CPU or Memory modification, the VRA logs show that a modify request to change the cpu parameters.

Expected behavior
The provider should modify all parameter, as long as they are valid.
Once the changes are pushed, Terraform should check the current resource state from VRA.
I manually performed a refresh. However, the provider still maintains the same state which is not same as actual VM config.

Cannot pass array of values in element of deployment_configuration or resource_configuration

vRA 7.x version
7.6
Terraform version
0.12.19
terraform-provider-vra7 plugin version
0.5.0

Describe the bug
Cannot pass array of values in element of deployment_configuration or resource_configuration. Arrays of values are necessary for some fields, based on catalog item template, but they are available to send through vRA API. Maybe there is a way but documentation is not suggesting any usage of this case whatsoever. In provider code the element of list is specified as schema.TypeString:

"deployment_configuration": {
	Type:     schema.TypeMap,
	Optional: true,
	Elem:     schema.TypeString,
},
"resource_configuration": {
	Type:     schema.TypeMap,
	Optional: true,
	Computed: true,
	Elem:     schema.TypeString,
}

To Reproduce
Steps to reproduce the behaviour:

  1. Terraform config file:
resource "vra7_deployment" "create_vnet" {

  catalog_item_name = "Network - Create vNet"

  resource_configuration = {
        "Network_-_Create_vNet.0" = null
        "Network_-_Create_vNet.alternativeWins" = ""
        "Network_-_Create_vNet.availableScopes" = ["10.0.0.0/24", "172.16.0.0/16"]
        "Network_-_Create_vNet.businessGroups" = ["1stbg"]
  }
}
  1. Terraform plan
  2. Validation Error

Expected behaviour
A array value should be possible to send. And if it is please provide with documentation.

Logs

2020/02/18 09:25:30 [TRACE] <root>: eval: *terraform.EvalValidateResource
2020/02/18 09:25:30 [ERROR] <root>: eval: *terraform.EvalValidateResource, err: Incorrect attribute value type: Inappropriate value for attribute "resource_configuration": element "Network_-_Create_vNet.businessGroups": string required.
2020/02/18 09:25:30 [ERROR] <root>: eval: *terraform.EvalSequence, err: Incorrect attribute value type: Inappropriate value for attribute "resource_configuration": element "Network_-_Create_vNet.businessGroups": string required.
[...]
2020/02/18 09:25:30 [TRACE] statemgr.Filesystem: removing lock metadata file .terraform.tfstate.lock.info
Error: Incorrect attribute value type

Desktop (please complete the following information):

  • OS: Mac OS X

ERROR: "resource_configuration" is not expected here.

vRA 7.6.x version
Version: 7.6.0 (Build: 13027133)
Terraform version
Terraform v0.12.24
terraform-provider-vra7 plugin version
provider.vra7 v1.0.1

Describe the bug
I want to set hostname of the machine i want to create. Here is my config file

provider "vra7" {
  username = "${var.username}"
  password = "${var.password}"
  tenant   = "${var.tenant}"
  host     = "${var.host}"
}

resource "vra7_deployment" "machine" {
  count             = 1
  catalog_item_name = "CentOS 7.0 x64"

  resource_configuration = {
    "Linux.cpu" = "2"
  }
}

when running command terraform plan, it throws below error

bash-4.2$ terraform plan

Error: Unsupported argument

  on main.tf line 13, in resource "vra7_deployment" "machine":
  13:   resource_configuration = {

An argument named "resource_configuration" is not expected here. Did you mean
to define a block of type "resource_configuration"?

To Reproduce
Steps to reproduce the behavior:

  1. Terraform config file
  2. Terraform command
  3. Error

Expected behavior
terraform plan command should not throw any error for 'resource_configuration' block.

Screenshots
If applicable, add screenshots to help explain your problem.

Logs
Attach logs to help debug the issue

  1. Attach vra-terraform.log
  2. Attach Terraform console log (Enable terraform logs following the steps mentioned in https://www.terraform.io/docs/configuration/environment-variables.html)
  3. crash.log(if any)

Desktop (please complete the following information):

  • OS: CentOS Linux 7

Additional context
Add any other context about the problem here.

Terraform adds resource in state file even though the request_status is "FAILED"

vRA 7.x version
7.4
Terraform version
v0.12.13
terraform-provider-vra7 plugin version
provider.vra7 v0.5.0

Describe the bug
While testing VM deployment, sometimes the machine provisioning fails and VRA returns and error "FAILED" with relevant reasons.
Expected behavior is TF stops deployment of that resource and does not add any entry into the state file.
What I have observed is that TF adds the resource in the state file .
When run a plan later, TF prompts an error "Error: The resource cannot be found"
image

Terraform state show output:
image

Expected behavior
TF should not add entries in the state file for failed components.

Desktop (please complete the following information):
OS: Ubuntu

Additional context
Add any other context about the problem here.

Issue terraform plan

vRA 7.x version
7.6
Terraform version
Terraform v0.13.5
terraform-provider-vra7 plugin version
The terraform-provider-vra7 plugin 2.0.1

Describe the bug
I am able to deploy VMs using the latest official provider. Once the VMS are deployed, if I run a TF plan, the provider shows that the "resource_configuration" options need to be changed.

Expected behavior
Since the configuration has not been modified, the provider should not try to modify the config.
This creates a confusion, if there are new resources that need to be deployed.

I read a comment that this bug was corrected, but I'm having the issued with last provider version.

lease_end field shows incorrect value and no change in lease_days always shows a change in plan

vRA 7.x version
vRA 7.6
Terraform version
The terraform version
terraform-provider-vra7 plugin version
v2.0.1

Describe the bug
The lease_end date is updated incorrectly after configuring lease_days in the initial deployment.
No change in lease_days shows a change in plan

To Reproduce
Steps to reproduce the behavior:

  1. Terraform config file
  2. Terraform command
  3. Error

Expected behavior
The lease_end date should be computed correctly and updated in the state file. If there is no change in lease_days, the plan should not show any update.

Screenshots
If applicable, add screenshots to help explain your problem.

Logs
Attach logs to help debug the issue

  1. Attach vra-terraform.log
  2. Attach Terraform console log (Enable terraform logs following the steps mentioned in https://www.terraform.io/docs/configuration/environment-variables.html)
  3. crash.log(if any)

Desktop (please complete the following information):

  • OS: [e.g. iOS]

Additional context
Add any other context about the problem here.

Provider panics during resource deletion when connection to vRA is lost

vRA 7.x version
1.0.1
Terraform version
0.12.24

Describe the bug
During resource deletion when the GetRequestStatus call in waitForRequestCompletion to vRA API is not responding for whatever reason (an intermittent connection issue for example) the provider will panic with a runtime error: invalid memory address or nil pointer dereference.

677:	        	reqestStatusView, _ := vraClient.GetRequestStatus(requestID)
688:		status = reqestStatusView.Phase // --> this fails with a nil pointer exception in case vRA doesn't respond to the API call

To Reproduce

  • Trigger resource deletion (might also work during resource creation)
  • break network connectivity to the vRA API for a short time (10 seconds, during the waitForRequestCompletion loop)

Expected behavior
There should be a error checking and/or retry mechanism that doesn't lead the provider to panic when network connectivity to the vRA API is lost intermittently

Terraform returns "The resource cannot be found" when vRA deployment succeeds

vRA 7.x version
7.5.0
Terraform version
0.12.7
terraform-provider-vra7 plugin version
0.4.1

Describe the bug
I tried to create Linux machines with a vRA XaaS.
This XaaS triggers a first workflow (with the ID "1"). It is used to instantiate resourceActions to create every needed resources for the machine.
It also instantiates another blueprint called "Linux" triggering a second workflow (with the ID "2") which aims to create the linux machine.

Terraform --> vRA XaaS blueprint --> 1st vRO workflow --> Linux blueprint --> 2nd vRO workflow

Terraform deployment is based on ID "1". When it ends, it makes the following API call to retrieve the machine's information:
GET https://{vra}/catalog-service/api/consumer/requests/{ID_1}/resourceViews

In my case, all the machine information are attached to ID "2", so at the end of the deployment, Terraform returns the error:

Error: The resource cannot be found

  on main.tf line 8, in resource "vra7_deployment" "Test-VM":
   8: resource "vra7_deployment" "Test-VM" {

Expected behavior
Would it be possible to allow Terraform to get resources' information from another ID than the one given in the first place for the deployment?

It's not possible to use custom resource actions

vRA 7.x version
7.6
Terraform version
0.12.19
terraform-provider-vra7 plugin version
0.5.0

Describe the bug
When resource action with name Reconfigure is not defined in resourceActions.Content.Operations i get an error:

 Update is not allowed for resource e64b02c9-6f1f-44ed-904a-eb79e17c5a5d, your entitlement has no Reconfigure action enabled

We only use custom resource actions and have disabled Reconfigure action, because it would expose our custom VM properties, which we don't want to. Part of code responsible for throwing error:

for _, op := range resources.Operations {
	if op.Name == sdk.Reconfigure {
		reconfigureEnabled = true
		reconfigureActionID = op.OperationID
		break
	}
}
// if reconfigure action is not available for any resource of the deployment
// return with an error message
if !reconfigureEnabled {
	return fmt.Errorf("Update is not allowed for resource %v, your entitlement has no Reconfigure action enabled", resources.ID)
}

Are there any plans for supporting custom resource actions? Thanks

Problem with cluster value (not integer)

vRA 7.6 version
The vRA 7.6 version where is issue is found.
Terraform version
Terraform v0.12.24
terraform-provider-vra7 plugin version

  • provider.vra7 v2.0.1

Describe the bug
Since I upgrade the terraform provider to 2.0.1 the cluster information should be informed.
I tried the following options:
-1 - Terraform show this message:
Code:20117 Message:The data specified within the request is invalid. SystemMessage:The data specified within the request is invalid.} {Code:11002 Message:The value of the '_cluster' field cannot be less than 1
0 - Terraform show this message:
Code:20117 Message:The data specified within the request is invalid. SystemMessage:The data specified within the request is invalid.} {Code:11003 Message:The value of the '_cluster' field cannot be more than 1
1 - Terraform show this message:
An internal error occurred. Details: [Cluster size is not integer for a component in blueprint:
2 - Terraform show this message:
Code:20117 Message:The data specified within the request is invalid. SystemMessage:The data specified within the request is invalid.} {Code:11003 Message:The value of the '_cluster' field cannot be more than 1.

If i downgrade the provider to 1.0.1 everything works as expected.

I am using terraform with CentOS 8.

--- resource.tf file:
resource "vra7_deployment" "test" {
count = 1
catalog_item_id = var.catalog_item_id
businessgroup_id = var.businessgroup_id
description = "HTTPS Server - TerraForm"
reasons = "https"
deployment_configuration = {
_leaseDays = "0"
_number_of_instances = 1
_deploymentName= "https"
deployment_property = "Team"
}

resource_configuration {
component_name = var.component_XAAS
cluster = 1
configuration = {
.. REMOVED
}
}
resource_configuration {
component_name = "OS_Linux"
cluster = 1
configuration = {
.. REMOVED
}
}
wait_timeout = 20
}

Vra7

Is this Vra7 provider accomodate On prem vra7? Or only vmware Cloud?

Building this provider fails accessing https://git.apache.org/thrift.git

I was trying to build the master branch of this provider to try the changes from the pull request "Pull network info from NETWORK_LIST json in resourceview" (#30). It now fails at:

go: git.apache.org/[email protected]: git fetch -f origin refs/heads/*:refs/heads/* refs/tags/*:refs/tags/* in F:\Tools\TerraForm\_Providers\terraform-provider-vra7\build\pkg\mod\cache\vcs\83dba939f95a790e497d565fc4418400145a1a514f955fa052f662d56e920c3e: exit status 128:
	fatal: unable to access 'https://git.apache.org/thrift.git/': Failed to connect to git.apache.org port 443: Timed out
go: error loading module requirements

From https://status.apache.org/, it seems that the repo "git.apache.org is not available at this time" and according to the referred blog may not be for some time.

It seems that thrift may now be available in other places like https://gitbox.apache.org/repos/asf/thrift.git or https://github.com/apache/thrift. I tried replacing in this repo all references to git.apache.org to one of those, but it still fails for the same reason. May be it's a dependency, but I don't know enough about this to figure out how to address this problem.

panic when tfstate file exists but doesn't have much in it

vRA 7.x version
7.6
Terraform version
0.12.19
terraform-provider-vra7 plugin version
0.5.0

Describe the bug
I got a panic on apply when I had a semi-empty tfstate file that contained this:

{
  "version": 4,
  "terraform_version": "0.12.20",
  "serial": 1,
  "lineage": "8019ce29-5d1c-a372-1533-b4bd24a7e1c0",
  "outputs": {},
  "resources": []
}

here's the error I got:

vra7_deployment.nazwa_resource: Creating...
vra7_deployment.nazwa_resource: Still creating... [10s elapsed]
vra7_deployment.nazwa_resource: Still creating... [20s elapsed]
vra7_deployment.nazwa_resource: Still creating... [30s elapsed]
vra7_deployment.nazwa_resource: Still creating... [40s elapsed]
vra7_deployment.nazwa_resource: Still creating... [50s elapsed]
vra7_deployment.nazwa_resource: Still creating... [1m0s elapsed]
vra7_deployment.nazwa_resource: Still creating... [1m10s elapsed]
vra7_deployment.nazwa_resource: Still creating... [1m20s elapsed]
vra7_deployment.nazwa_resource: Still creating... [1m30s elapsed]
vra7_deployment.nazwa_resource: Still creating... [1m40s elapsed]
vra7_deployment.nazwa_resource: Still creating... [1m50s elapsed]
vra7_deployment.nazwa_resource: Still creating... [2m0s elapsed]
vra7_deployment.nazwa_resource: Still creating... [2m10s elapsed]
vra7_deployment.nazwa_resource: Still creating... [2m20s elapsed]
vra7_deployment.nazwa_resource: Still creating... [2m30s elapsed]
vra7_deployment.nazwa_resource: Still creating... [2m40s elapsed]
vra7_deployment.nazwa_resource: Still creating... [2m50s elapsed]
vra7_deployment.nazwa_resource: Still creating... [3m0s elapsed]
vra7_deployment.nazwa_resource: Still creating... [3m10s elapsed]
vra7_deployment.nazwa_resource: Still creating... [3m20s elapsed]
vra7_deployment.nazwa_resource: Still creating... [3m30s elapsed]
vra7_deployment.nazwa_resource: Still creating... [3m40s elapsed]
vra7_deployment.nazwa_resource: Still creating... [3m50s elapsed]
vra7_deployment.nazwa_resource: Still creating... [4m0s elapsed]
vra7_deployment.nazwa_resource: Still creating... [4m10s elapsed]
vra7_deployment.nazwa_resource: Still creating... [4m20s elapsed]
vra7_deployment.nazwa_resource: Still creating... [4m30s elapsed]
vra7_deployment.nazwa_resource: Still creating... [4m40s elapsed]
vra7_deployment.nazwa_resource: Still creating... [4m50s elapsed]

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


panic: runtime error: invalid memory address or nil pointer dereference
2020-03-10T15:08:25.361+0100 [DEBUG] plugin.terraform-provider-vra7_v0.5.0_x4: [signal SIGSEGV: segmentation violation code=0x1 addr=0x28 pc=0x19fb33e]
2020-03-10T15:08:25.361+0100 [DEBUG] plugin.terraform-provider-vra7_v0.5.0_x4:
2020-03-10T15:08:25.361+0100 [DEBUG] plugin.terraform-provider-vra7_v0.5.0_x4: goroutine 55 [running]:
2020-03-10T15:08:25.361+0100 [DEBUG] plugin.terraform-provider-vra7_v0.5.0_x4: github.com/terraform-providers/terraform-provider-vra7/vra7.waitForRequestCompletion(0xc0002ada40, 0x1c24e40, 0xc00039c300, 0xc00016c120, 0x24, 0x1, 0x1, 0x1, 0xc00055f080)
2020-03-10T15:08:25.361+0100 [DEBUG] plugin.terraform-provider-vra7_v0.5.0_x4: 	/opt/teamcity-agent/work/5d79fe75d4460a2f/src/github.com/terraform-providers/terraform-provider-vra7/vra7/resource_vra7_deployment.go:588 +0x1be
2020-03-10T15:08:25.361+0100 [DEBUG] plugin.terraform-provider-vra7_v0.5.0_x4: github.com/terraform-providers/terraform-provider-vra7/vra7.resourceVra7DeploymentCreate(0xc0002ada40, 0x1c24e40, 0xc00039c300, 0x2, 0x27bdc60)
2020-03-10T15:08:25.361+0100 [DEBUG] plugin.terraform-provider-vra7_v0.5.0_x4: 	/opt/teamcity-agent/work/5d79fe75d4460a2f/src/github.com/terraform-providers/terraform-provider-vra7/vra7/resource_vra7_deployment.go:198 +0xdda
2020-03-10T15:08:25.361+0100 [DEBUG] plugin.terraform-provider-vra7_v0.5.0_x4: github.com/terraform-providers/terraform-provider-vra7/vendor/github.com/hashicorp/terraform/helper/schema.(*Resource).Apply(0xc00046e000, 0xc00012e460, 0xc00000cd00, 0x1c24e40, 0xc00039c300, 0xc000387301, 0xc000396240, 0x1af2200)
2020-03-10T15:08:25.361+0100 [DEBUG] plugin.terraform-provider-vra7_v0.5.0_x4: 	/opt/teamcity-agent/work/5d79fe75d4460a2f/src/github.com/terraform-providers/terraform-provider-vra7/vendor/github.com/hashicorp/terraform/helper/schema/resource.go:287 +0x3b4
2020-03-10T15:08:25.361+0100 [DEBUG] plugin.terraform-provider-vra7_v0.5.0_x4: github.com/terraform-providers/terraform-provider-vra7/vendor/github.com/hashicorp/terraform/helper/schema.(*Provider).Apply(0xc00046e080, 0xc0005bda58, 0xc00012e460, 0xc00000cd00, 0xc0002b0e08, 0xc0000ae620, 0x1af4120)
2020-03-10T15:08:25.361+0100 [DEBUG] plugin.terraform-provider-vra7_v0.5.0_x4: 	/opt/teamcity-agent/work/5d79fe75d4460a2f/src/github.com/terraform-providers/terraform-provider-vra7/vendor/github.com/hashicorp/terraform/helper/schema/provider.go:285 +0x18f
2020-03-10T15:08:25.361+0100 [DEBUG] plugin.terraform-provider-vra7_v0.5.0_x4: github.com/terraform-providers/terraform-provider-vra7/vendor/github.com/hashicorp/terraform/helper/plugin.(*GRPCProviderServer).ApplyResourceChange(0xc0000ae040, 0x1ebfa20, 0xc0003865a0, 0xc00039d980, 0xc0000ae040, 0xc0003865a0, 0xc00022dbd0)
2020-03-10T15:08:25.361+0100 [DEBUG] plugin.terraform-provider-vra7_v0.5.0_x4: 	/opt/teamcity-agent/work/5d79fe75d4460a2f/src/github.com/terraform-providers/terraform-provider-vra7/vendor/github.com/hashicorp/terraform/helper/plugin/grpc_provider.go:885 +0x894
2020-03-10T15:08:25.361+0100 [DEBUG] plugin.terraform-provider-vra7_v0.5.0_x4: github.com/terraform-providers/terraform-provider-vra7/vendor/github.com/hashicorp/terraform/internal/tfplugin5._Provider_ApplyResourceChange_Handler(0x1c1cee0, 0xc0000ae040, 0x1ebfa20, 0xc0003865a0, 0xc0000c7db0, 0x0, 0x1ebfa20, 0xc0003865a0, 0xc0000e6900, 0x448)
2020-03-10T15:08:25.361+0100 [DEBUG] plugin.terraform-provider-vra7_v0.5.0_x4: 	/opt/teamcity-agent/work/5d79fe75d4460a2f/src/github.com/terraform-providers/terraform-provider-vra7/vendor/github.com/hashicorp/terraform/internal/tfplugin5/tfplugin5.pb.go:3217 +0x23e
2020-03-10T15:08:25.362+0100 [DEBUG] plugin.terraform-provider-vra7_v0.5.0_x4: github.com/terraform-providers/terraform-provider-vra7/vendor/google.golang.org/grpc.(*Server).processUnaryRPC(0xc00055e300, 0x1eca9e0, 0xc00054cc00, 0xc0003a0000, 0xc000391f80, 0x2792d40, 0x0, 0x0, 0x0)
2020-03-10T15:08:25.362+0100 [DEBUG] plugin.terraform-provider-vra7_v0.5.0_x4: 	/opt/teamcity-agent/work/5d79fe75d4460a2f/src/github.com/terraform-providers/terraform-provider-vra7/vendor/google.golang.org/grpc/server.go:966 +0x470
2020-03-10T15:08:25.362+0100 [DEBUG] plugin.terraform-provider-vra7_v0.5.0_x4: github.com/terraform-providers/terraform-provider-vra7/vendor/google.golang.org/grpc.(*Server).handleStream(0xc00055e300, 0x1eca9e0, 0xc00054cc00, 0xc0003a0000, 0x0)
2020-03-10T15:08:25.362+0100 [DEBUG] plugin.terraform-provider-vra7_v0.5.0_x4: 	/opt/teamcity-agent/work/5d79fe75d4460a2f/src/github.com/terraform-providers/terraform-provider-vra7/vendor/google.golang.org/grpc/server.go:1245 +0xd25
2020-03-10T15:08:25.362+0100 [DEBUG] plugin.terraform-provider-vra7_v0.5.0_x4: github.com/terraform-providers/terraform-provider-vra7/vendor/google.golang.org/grpc.(*Server).serveStreams.func1.1(0xc00003a0a0, 0xc00055e300, 0x1eca9e0, 0xc00054cc00, 0xc0003a0000)
2020-03-10T15:08:25.362+0100 [DEBUG] plugin.terraform-provider-vra7_v0.5.0_x4: 	/opt/teamcity-agent/work/5d79fe75d4460a2f/src/github.com/terraform-providers/terraform-provider-vra7/vendor/google.golang.org/grpc/server.go:685 +0x9f
2020-03-10T15:08:25.362+0100 [DEBUG] plugin.terraform-provider-vra7_v0.5.0_x4: created by github.com/terraform-providers/terraform-provider-vra7/vendor/google.golang.org/grpc.(*Server).serveStreams.func1
2020-03-10T15:08:25.362+0100 [DEBUG] plugin.terraform-provider-vra7_v0.5.0_x4: 	/opt/teamcity-agent/work/5d79fe75d4460a2f/src/github.com/terraform-providers/terraform-provider-vra7/vendor/google.golang.org/grpc/server.go:683 +0xa1
2020/03/10 15:08:25 [DEBUG] vra7_deployment.nazwa_resource: apply errored, but we're indicating that via the Error pointer rather than returning it: rpc error: code = Unavailable desc = transport is closing
2020/03/10 15:08:25 [TRACE] <root>: eval: *terraform.EvalMaybeTainted
2020/03/10 15:08:25 [TRACE] EvalMaybeTainted: vra7_deployment.nazwa_resource encountered an error during creation, so it is now marked as tainted
2020/03/10 15:08:25 [TRACE] <root>: eval: *terraform.EvalWriteState
2020/03/10 15:08:25 [TRACE] EvalWriteState: removing state object for vra7_deployment.nazwa_resource
2020/03/10 15:08:25 [TRACE] <root>: eval: *terraform.EvalApplyProvisioners
2020/03/10 15:08:25 [TRACE] EvalApplyProvisioners: vra7_deployment.nazwa_resource has no state, so skipping provisioners
2020/03/10 15:08:25 [TRACE] <root>: eval: *terraform.EvalMaybeTainted
2020/03/10 15:08:25 [TRACE] EvalMaybeTainted: vra7_deployment.nazwa_resource encountered an error during creation, so it is now marked as tainted
2020/03/10 15:08:25 [TRACE] <root>: eval: *terraform.EvalWriteState
2020/03/10 15:08:25 [TRACE] EvalWriteState: removing state object for vra7_deployment.nazwa_resource
2020/03/10 15:08:25 [TRACE] <root>: eval: *terraform.EvalIf
2020/03/10 15:08:25 [TRACE] <root>: eval: *terraform.EvalIf
2020/03/10 15:08:25 [TRACE] <root>: eval: *terraform.EvalWriteDiff
2020/03/10 15:08:25 [TRACE] <root>: eval: *terraform.EvalApplyPost
2020/03/10 15:08:25 [ERROR] <root>: eval: *terraform.EvalApplyPost, err: rpc error: code = Unavailable desc = transport is closing
2020/03/10 15:08:25 [ERROR] <root>: eval: *terraform.EvalSequence, err: rpc error: code = Unavailable desc = transport is closing
2020/03/10 15:08:25 [TRACE] [walkApply] Exiting eval tree: vra7_deployment.nazwa_resource
2020/03/10 15:08:25 [TRACE] vertex "vra7_deployment.nazwa_resource": visit complete
2020/03/10 15:08:25 [TRACE] dag/walk: upstream of "provider.vra7 (close)" errored, so skipping
2020/03/10 15:08:25 [TRACE] dag/walk: upstream of "meta.count-boundary (EachMode fixup)" errored, so skipping
2020/03/10 15:08:25 [TRACE] dag/walk: upstream of "root" errored, so skipping
2020-03-10T15:08:25.364+0100 [DEBUG] plugin: plugin process exited: path=/Users/karolsokolowski/GIT/ochk-terraform-vra7-tests/examples/create_centOS/.terraform/plugins/darwin_amd64/terraform-provider-vra7_v0.5.0_x4 pid=15270 error="exit status 2"
2020/03/10 15:08:25 [TRACE] statemgr.Filesystem: not making a backup, because the new snapshot is identical to the old
2020/03/10 15:08:25 [TRACE] statemgr.Filesystem: no state changes since last snapshot
2020/03/10 15:08:25 [TRACE] statemgr.Filesystem: writing snapshot at terraform.tfstate
2020/03/10 15:08:25 [TRACE] statemgr.Filesystem: removing lock metadata file .terraform.tfstate.lock.info
2020/03/10 15:08:25 [TRACE] statemgr.Filesystem: unlocking terraform.tfstate using fcntl flock
2020-03-10T15:08:25.376+0100 [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 Terraform[1] 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.

SECURITY WARNING: the "crash.log" file that was created may contain
sensitive information that must be redacted before it is safe to share
on the issue tracker.

[1]: https://github.com/hashicorp/terraform/issues

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

To Reproduce
Steps to reproduce the behavior:
I'm just trying to create a vra7 machine using terraform apply.

Expected behavior
No panic, tfstate file written with new machine details

Need to import existing VMs

Use case - we need to import existing VMs from a legacy system using terraform import for a new vRA 7.6 solution.

Drift in state file

vRA 7.x version
vRA 7.6 HF 7
Terraform version
Terraform v0.12.26
terraform-provider-vra7 plugin version
provider.vra7 v1.0.1

Describe the bug

I am using vra-7 provider and I have built 11 VM's with Terraform via vRA.

I see all of the 11 VM's getting created via vRA but the state file have details of only 8 servers and this is random, sometimes if I build 15 servers I only have 4 servers details in my state file.

From what I can see in the trace log, output, and configuration, the failure appears to be in the contents of the API response on the read. Terraform appears to send the creation request with the appropriate value, and receives back a successful creation response. It then performs the read, which also appears to succeed, it just does not have the complete contents.

I am able to get hold of the REST API endpoint this provider is using for the final read is documented here, showing that there are page and limit parameters:

https://code.vmware.com/apis/39/vrealize-automation#/catalog-service/%2Fapi%2Fconsumer%2Frequests%2F%7Bid%7D%2FresourceViews

I am able to get the API working and did a GET call via Postman and found the following,

I need to hit 3 pages to pull all of my 11 servers information

$ grep -i VirtualMachineName page1 | wc -l
5
$ grep -i VirtualMachineName page 2 | wc -l
2
$ grep -i VirtualMachineName page3 |wc -l
4

page -1+page -2+page -3 = 11 servers (total servers of my vRA deployment)

So from the above I need to traverse through 3 pages to get all of my 11 servers information but I feel terraform is only grabbing the info on first page of API, but not on all.

To Reproduce
Deploy VM's with software component attached to it. Hit the following API, to see if you have all of your servers.

curl --location --request GET 'https:///catalog-service/api/consumer/requests//resourceViews'
--header 'Authorization: Bearer xxxx'
--data-raw ''

Expected behavior
Would it be possible to allow Terraform to get ifo of all pages on the mentioned API?

Screenshots
N/A

Logs
N/A

Desktop (please complete the following information):

  • N/A

Additional context
N/A

Feature request: Day 2: Change the number of VMs created by the vRA blueprint

I have a vRA blueprint that contains a cluster of 1 to 5 EC2 Servers:

image

I have a terraform configuration that deploys this blueprint

resource "vra7_deployment" "min_max" {
  wait_timeout = "20"
  catalog_item_name = "min-max"

  resource_configuration = {
    EC2_Cluster._cluster = "3"
    EC2_Cluster.ip_address = ""
  }
}

This successfully deploys my blueprint and creates 3 VMs.

If I change EC2_Cluster._cluster = "3" to EC2_Cluster._cluster = "5" and run Terraform apply the apply completes successfully but does nothing. I don't get 2 new VMs.

Is this expected? Am I doing something incorrectly?

Can't access vars in resource_configuration

vRA 7.x version
Version: 7.5.0 (Build: 10053500)

Terraform version
Terraform v0.14.4

terraform-provider-vra7 plugin version

  • provider registry.terraform.io/vmware/vra7 v3.0.0

Describe the bug

Variables inside resource_configuration blocks are inaccessible.

Hello,

After huge gobs of pain I had deployment working under Terraform 11. I have just been through the various upgrade steps to move to V14 but I am now unable to access vars in resource_configuration. I've spent a day and a half searching and trying things I've found here and elsewhere without any real progress. Terraform complains Error: Invalid template interpolation value: Cannot include the given value in a string template: string required. after the VM is deployed successfully and stops.

I've seen that this problem has been experienced by others. I've tried things with and without count but I really want it to remain to permit mutilple deployments. My script looks in part like this:

...
output "ansible-master-IP-address" {
  value = vra7_deployment.ansible_master[*].resource_configuration[*].instances[*].properties.ip_address
}

output "ansible-master-name" {
  value = vra7_deployment.ansible_master[*].resource_configuration[*].instances[*].properties.name
}

provider "vra7" {
  username = var.vra_user
  password = var.vra_password
  tenant   = "XXXXXXX"
  host     = "https://secret.com/"
  insecure = false
}

resource "vra7_deployment" "ansible_master" {
  businessgroup_name = "dev"
  catalog_item_name  = "Red Hat Enterprise Linux 8"
  count              = 1
  description        = "Ansible master."
  reasons            = "Automation"
  wait_timeout       = 30
  lease_days         = 390

  resource_configuration {
    component_name = "RHEL8"
    configuration = {
      cpu         = "1"
      memory      = "4096"
      description = "Ansible master"
      ip_address  = ""
      name        = ""
    }
  }

  deployment_configuration = {
    _number_of_instances = 1
  }

  # Copy the files.
  provisioner "file" {
    source      = "ansible/"
    destination = "./"

    connection {
      type     = "ssh"
      host     = "${self.resource_configuration[*].instances[*].properties.name}.domain.com"
      user     = var.vra_user
      password = var.vra_password
    }
  }

...

I've tried splats, as seen in the output vars. I've tried self as seen in the file provisioner connection block. I've tried with and without properties and instances and many other things and I still can't get this to run. vra7_deployment.ansible_master[*] in connection also fails. Can someone help, please, as this really does seem like a bug rather than a 'feature' and no amount of trying will make it work here? It shouldn't be this hard especially given that it worked previously.

Thanks.

To Reproduce
As described above. Even paths which work from terraform console do not work in production.

Expected behavior
Variables inside resource_configuration should be accessible.

Output missing when relying on defaults for "resource_configuration"

vRA 7.x version
7.6
Terraform version
0.12.24
terraform-provider-vra7 plugin version
1.0.2

Describe the bug
The vRA 7 provider allows a user to specify configuration of individual resources from a blueprint. This is done through the resource_configuration section. However, a user is also permitted to omit this section, which should pull in the default values specified in the blueprint. When the resource_configuration section is omitted, any computed outputs from the resources are missing.

To Reproduce
Steps to reproduce the behavior:

  1. Use a config file similar to this:
resource "vra7_deployment" "machine" {
  count             = 1
  catalog_item_name = "Ubuntu 18"
  description = "some description"
  reasons = "some reason"
  lease_days = 10

  deployment_configuration = {
    "blueprint_custom_property" = "This is a blueprint custom property"
  }
}
  1. Run terraform plan and terraform apply
  2. The resources are provisioned, but the resource data is missing from the state file.

Expected behavior
Computed data is present in the .tfstate file:
https://gist.github.com/prydin/0809bed0e8f0fb118d8e3b35bd46b3b7

Actual Behavior
Computed values, such as IDs and IP addresses are missing as is evident here: https://gist.github.com/prydin/0050cf26c70b98c8ad4a3d4d5547b03a

Desktop (please complete the following information):

  • Mac

VRA Provider deletes resources from state file before receiving any "SUCCESSFUL" status response from VRA during terraform destroy

vRA 7.x version
7.4
Terraform version
v0.12.13
terraform-provider-vra7 plugin version
provider.vra7 v0.5.0

Describe the bug
. Our environment has a pre approval setup where my credentials does not have rights to destroy resources directly. A destroy request needs to be approved by someone with elevated access rights. Once approved, I can see the VMs are destroyed in VRA UI.
I tried to destroy two Linux VMs I created using TF. The provider sends status request to VRA periodically and receives update "Status: PENDING_PRE_APPROVAL".
This continues for around 15 mins and then TF removes the resources from the state file with a message
image

This is not expected behavior. I assumed that after 15mins the provider may timeout the request and stop the destroy task and maintain the state file since VRA did not delete the VMs yet.

If I check the VRA UI, then I see the destroy request is yet to be approved.
Also the last status response from TF LOG file was still "Request status: PENDING_PRE_APPROVAL."
image
image

Expected behavior
The provider should not delete the resources from state file unless it receives a "SUCCESSFUL" response from VRA. If it times out, then TF should maintain the resource state.

Desktop (please complete the following information):

  • OS: Ubuntu

Additional context
Add any other context about the problem here.

Does 'import' work?

versions
Terraform v0.12.7
+ provider.vra7 v0.4.1

Describe the bug
terraform import fails on authentication. It appears as if it is not sending the user name correctly.

To Reproduce
Steps to reproduce the behavior:

  1. Module module.MASTER.vra7_deployment.vra-chef is instantiated and applied
  2. Terraform command: terraform import module.MASTER.vra7_deployment.vra-chef 5021936a-66c7-01d4-bb16-41ca96c3517b
  3. Error:
Error: Error: Unable to get auth token: vRealize API: [{Code:90135 Message:Unable to authenticate user  in tenant Engineering. SystemMessage:90135-Unable to authenticate user  in tenant Engineering.} {Code:400 Message: SystemMessage:}]

  on modules\vra-chef\main.tf line 5, in provider "vra7":
   5: provider "vra7" {

Expected behavior
Terraform imports the machine specified into the resource ID. I have never actually seen this happen so I'm not 100% sure what to expect.

Screenshots
If applicable, add screenshots to help explain your problem.

Logs
Attach logs to help debug the issue

  1. Attach vra-terraform.log
    vra-terraform.log

  2. Attach Terraform console log (Enable terraform logs following the steps mentioned in https://www.terraform.io/docs/configuration/environment-variables.html)
    PowerShell_transcript.CHI-MAXCA-10-01.qB5pgV5r.20190904164316.txt

  3. crash.log(if any)

Desktop (please complete the following information):
Win10

Additional context
Add any other context about the problem here.

Provider 1.0.1 - Required to specify leasedays even if there's a default specified in the blueprint

vRA 7.x version
vRealize Automation 7.6

Terraform version
v0.12.24

terraform-provider-vra7 plugin version
The terraform-provider-vra7 plugin version 1.0.1

Describe the bug
Issue #60 fixed the cluster requirement but not the leasedays

To Reproduce
Steps to reproduce the behavior:

  1. maint.tf content
provider "vra7" {
    username = var.vra_username
    password = var.vra_password
    tenant = var.vra_tenant
    host = var.vra_host
    insecure = true
}

resource "vra7_deployment" "deployment" {
  catalog_item_name = "dev vm"              
  reasons = "provide a reason"
  description = "provide a description"
  //lease_days = 2

  resource_configuration {
    component_name = "vm1"

    //Please Provide the following information for the bootstrap node component
    configuration = {
      "custom.midname" = "BASE"
    }
  } 
}
  1. Terraform command
    terraform apply

  2. Error
    Error: The catalog item request failed with error vRealize API: [{Code:20117 Mes
    sage:The data specified within the request is invalid. SystemMessage:The data sp
    ecified within the request is invalid.} {Code:11002 Message:The value of the '_l
    easeDays' field cannot be less than 2. SystemMessage:The value of the field with
    id _leaseDays cannot be less than 2.} {Code:400 Message: SystemMessage:}]

Expected behavior
Don't declare property value when default exist in the blueprint

Desktop (please complete the following information):

  • OS: Windows 2016 and CentOS 7

Missing disk documentation and examples

vRA 7.x version
7.6
Terraform version
0.13.5
terraform-provider-vra7 plugin version
2.0.0

Describe the bug
There is no documentation on either GitHub or at https://www.terraform.io/docs/providers/vra7/index.html of how to add an additional disk to a VM. Examples would be useful as well.

To Reproduce

  1. Browse documentation
  2. Browse source code
  3. Search Google
  4. Raise issue

Expected behavior
Clearly documenteed supported parameters for defining disks

Screenshots
NA

Logs
NA

Desktop (please complete the following information):

  • OS: Linux

Additional context
Add any other context about the problem here.

Output issue with resource_configuration

vRA 7.5 version
The vRA 7.5 version where is issue is found.
Terraform version
0.12.24
**terraform-provider-vra7 plugin version
1.0.1

Describe the bug
When it try to output my result, i'm not able to acces

To Reproduce
Steps to reproduce the behavior:

  1. Terraform config file
resource "vra7_deployment" "windows" {
  count             = 1
...
  resource_configuration {
    component_name = "server1"
    configuration = {
      hostname = "ServerName"
   ...
   }
  ....
}
output "machine-names" {
  value = ["${vra7_deployment.windows[*].resource_configuration.server1.hostname}"]
}
  1. Terraform command
    terraform apply
  2. Error
    `Error: Unsupported attribute

on main.tf line 125, in output "machine-names":
125: value = ["${vra7_deployment.windows[*].resource_configuration.server1.hostname}"]

This value does not have any attributes.`
(server1 is underlined)

Expected behavior
It should output the hostname

Terraform refresh does not work as intended.

vRA 7.x version
7.4
Terraform version
v0.12.13
terraform-provider-vra7 plugin version
provider.vra7 v0.5.0

Describe the bug
During deployment of VM resource, TF timesout (using default timeout value) although the VM request is still "IN PROGRESS" on VRA.
TF show output when TF timesout:

vra7_deployment.Windows_machine_01[0]: (tainted)

resource "vra7_deployment" "Windows_machine_01" {
businessgroup_name = "CP_PROD_CF_OBO_01"
catalog_item_id = "3a8b1715-7917-4589-b934-9c444184a642"
catalog_item_name = "IAAS-W2012-R2-Standard-x64-CF"
id = "ed158554-8395-4d5d-a39f-a7ca4c77662a"
request_status = "IN_PROGRESS"
resource_configuration = {

Once the VM is deployed, I assumed that using terraform refresh, the state file would be updated with current status.
TF refresh output once VM is successfully deployed:

vra7_deployment.Windows_machine_01[0]: (tainted)

resource "vra7_deployment" "Windows_machine_01" {
businessgroup_name = "CP_PROD_CF_OBO_01"
catalog_item_id = "3a8b1715-7917-4589-b934-9c444184a642"
catalog_item_name = "IAAS-W2012-R2-Standard-x64-CF"
id = "ed158554-8395-4d5d-a39f-a7ca4c77662a"
request_status = "IN_PROGRESS"
resource_configuration = {

Problem arises when I do a TF plan, since the VM is already deployed, TF should show that no changes are required.
However, I get a mesage that the "resource is tainted, so must be replaced"

image

Expected behavior
The resource status should be updated after terraform refresh.

Update the VM state (ie: power on/power off)

vRA 7.x version
vRA 7.3
Terraform version
Terraform v0.12.26

terraform-provider-vra7 plugin version
provider.vra7 v1.0.1

Describe the bug
Can't change state of the VM instances provisioned by Terraform through vRA.

Context
I build a VM through vRA using a terraform plan and the vRA7 provider successfully.
If I try to change the lease that's goes through without a problem, same if I change CPU or Mem.
I can't start a VM (that was powered off through vRA) by running a terraform updated plan.

Further details
If I shutdown the VM from vRA or vCenter, upon a state refresh the respective details are properly updated in the state file, so one can see its status and available actions per that status, for example:
Right after provisioing the VM through terraform (the VM is on), I have:

              "PowerOff": "true",
              "Reboot": "true",
              "Reconfigure": "true",
              "Reprovision": "true",
              "Reset": "true",
              "Shutdown": "true",
              "Suspend": "true",
     "status": ""

Whilst, after I've run shutdown (from vc or vra) following a terraform refresh I now have:

              "PowerOn": "true",
              "Reconfigure": "true",
              "Reprovision": "true",
     "status": "Off"

If I power the VM on from vRA, then I have:

              "PowerOff": "true",
              "Reboot": "true",
              "Reconfigure": "true",
              "Reprovision": "true",
              "Reset": "true",
              "Shutdown": "true",
              "Suspend": "true",
     "status": "on"

So, following this observation (while the VM was still poweroff) I've updated the main terraform plan by changing the state, once that hasn't worked, I've tried changing some of the other, like setting PowerOff=true (have had quite a few tries and combinations).
All terraform plans get applied successfully and in vRA under Requests tab I can see the "Reconfigure a machine" action that terraform instigates, finishing successfully as well.
The VM on the other hand, doesn't power on, or power off to that matter.

Conclusion
As mentioned, this may not be a bug, but I would have expected I can modify any of the resource properties after the initial provisioning. In case this is not a bug, an explanation as to how it all works would be highly appreciated.

To Reproduce
Steps to reproduce the behavior:

  1. The VM is already provisioned through terraform and I'm reapplying the following plan:

provider "vra7" {
username = var.vrauser
password = var.vrapass
tenant = var.vratenant
host = var.vrahost
insecure = true
}

resource "vra7_deployment" "TFTest01" {
count = 1
catalog_item_name = "RHEL7.6"
description = "test terraform deployment"
lease_days = 20
businessgroup_name = "icds_bg"

resource_configuration {
component_name = "vSphere_Machine_1"
configuration = {
cpu = 2
memory = 2234
custom_property = "Terraform custom property test"
Status = "On"
}
}
}

  1. Terraform command

terraform plan

2020/06/19 10:36:41 [WARN] Log levels other than TRACE are currently unreliable, and are supported only for backward compatibility.
Use TF_LOG=TRACE to see Terraform's internal logs.

Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

vra7_deployment.TFTest01[0]: Refreshing state... [id=46610d78-efa8-43f5-a840-3fb42e2335a5]

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

Terraform will perform the following actions:

vra7_deployment.TFTest01[0] will be updated in-place
~ resource "vra7_deployment" "TFTest01" {
businessgroup_id = "6e21cee9-126e-4c8a-b532-b97d6778739b"
businessgroup_name = "icds_bg"
catalog_item_id = "8db0471f-44fd-4595-a600-8399627f7b77"
catalog_item_name = "RHEL7.6"
date_created = "2020-06-18T21:08:48.204Z"
deployment_destroy = true
deployment_id = "3528b5af-07cd-4efc-976a-4b9a3afe226e"
description = "test terraform deployment"
id = "46610d78-efa8-43f5-a840-3fb42e2335a5"
last_updated = "2020-06-19T07:13:48.517Z"
lease_days = 20
lease_end = "2020-07-09T10:13:24.300Z"
lease_start = "2020-06-18T21:08:48.190Z"
name = "RHEL7.6-81936314"
owners = [
"octavian.teodorescu",
]
request_status = "FAILED"
tenant_id = "ICDS"
wait_timeout = 15

  - resource_configuration {
      - cluster            = 1 -> null
      - component_name     = "vSphere_Machine_1" -> null
      - configuration      = {
          - "CancelReconfigure"                   = "true"
          - "Component"                           = "vSphere_Machine_1"
          - "DISK_VOLUMES.0.DISK_CAPACITY"        = "20"
          - "DISK_VOLUMES.0.DISK_INPUT_ID"        = "DISK_INPUT_ID1"
          - "DISK_VOLUMES.0.DISK_LABEL"           = "Hard disk 1"
          - "EXTERNAL_REFERENCE_ID"               = "vm-882"
          - "ExecuteReconfigure"                  = "true"
          - "GetExpirationReminder"               = "true"
          - "IS_COMPONENT_MACHINE"                = "false"
          - "MachineBlueprintName"                = "RHEL7.6"
          - "MachineDailyCost"                    = "0"
          - "MachineDestructionDate"              = "2020-07-09T10:13:24.000Z"
          - "MachineExpirationDate"               = "2020-07-09T10:13:24.000Z"
          - "MachineGroupName"                    = "icds_bg"
          - "MachineGuestOperatingSystem"         = "Red Hat Enterprise Linux 7 (64-bit)"
          - "MachineInterfaceDisplayName"         = "vSphere (vCenter)"
          - "MachineInterfaceType"                = "vSphere"
          - "MachineReservationName"              = "ansible-reservation"
          - "NETWORK_LIST.0.NETWORK_ADDRESS"      = "xx.xxx.9.12"
          - "NETWORK_LIST.0.NETWORK_MAC_ADDRESS"  = "00:50:56:be:78:df"
          - "NETWORK_LIST.0.NETWORK_NAME"         = "DPortGroup"
          - "NETWORK_LIST.0.NETWORK_NETWORK_NAME" = "SLNetwork192"
          - "NETWORK_LIST.0.NETWORK_PROFILE"      = "SL Network 192"
          - "VirtualMachine.Admin.UUID"           = "503e5bb7-d639-8cb7-790e-52e176e43660"
          - "cpu"                                 = "2"
          - "endpointExternalReferenceId"         = "f65a17da-87ef-4350-a9ec-8c19ebff3790"
          - "ip_address"                          = "xx.xxx.9.12"
          - "machineId"                           = "e8d0b355-ffd5-4f06-9c5b-ecf9c64951d5"
          - "memory"                              = "2234"
          - "name"                                = "AZ0022"
          - "storage"                             = "20"
          - "type"                                = "Virtual"
        } -> null
      - date_created       = "2020-06-18T21:15:38.697Z" -> null
      - ip_address         = "xx.xxx.9.12" -> null
      - last_updated       = "2020-06-19T07:13:52.109Z" -> null
      - name               = "AZ0022" -> null
      - parent_resource_id = "3528b5af-07cd-4efc-976a-4b9a3afe226e" -> null
      - request_id         = "46610d78-efa8-43f5-a840-3fb42e2335a5" -> null
      - request_state      = "SUCCESSFUL" -> null
      - resource_id        = "9fb7ca4f-4307-40e3-9dbb-d74ac25bf213" -> null
      - resource_type      = "Infrastructure.Virtual" -> null
      - status             = "Off (Reconfigure failed, waiting to retry)" -> null
    }
  + resource_configuration {
      + cluster            = (known after apply)
      + component_name     = "vSphere_Machine_1"
      + configuration      = {
          + "Status"          = "On"
          + "cpu"             = "2"
          + "custom_property" = "Terraform custom property test"
          + "memory"          = "2560"
        }
      + date_created       = (known after apply)
      + description        = (known after apply)
      + ip_address         = (known after apply)
      + last_updated       = (known after apply)
      + name               = (known after apply)
      + parent_resource_id = (known after apply)
      + request_id         = (known after apply)
      + request_state      = (known after apply)
      + resource_id        = (known after apply)
      + resource_type      = (known after apply)
      + status             = (known after apply)
    }
}

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


Note: You didn't specify an "-out" parameter to save this plan, so Terraform
can't guarantee that exactly these actions will be performed if
"terraform apply" is subsequently run.

Then I run apply:

terraform apply -auto-approve
2020/06/19 10:38:05 [WARN] Log levels other than TRACE are currently unreliable, and are supported only for backward compatibility.
Use TF_LOG=TRACE to see Terraform's internal logs.

vra7_deployment.TFTest01[0]: Refreshing state... [id=46610d78-efa8-43f5-a840-3fb42e2335a5]
vra7_deployment.TFTest01[0]: Modifying... [id=46610d78-efa8-43f5-a840-3fb42e2335a5]
vra7_deployment.TFTest01[0]: Still modifying... [id=46610d78-efa8-43f5-a840-3fb42e2335a5, 10s elapsed]
vra7_deployment.TFTest01[0]: Still modifying... [id=46610d78-efa8-43f5-a840-3fb42e2335a5, 20s elapsed]
vra7_deployment.TFTest01[0]: Still modifying... [id=46610d78-efa8-43f5-a840-3fb42e2335a5, 30s elapsed]
vra7_deployment.TFTest01[0]: Still modifying... [id=46610d78-efa8-43f5-a840-3fb42e2335a5, 40s elapsed]
vra7_deployment.TFTest01[0]: Still modifying... [id=46610d78-efa8-43f5-a840-3fb42e2335a5, 50s elapsed]
vra7_deployment.TFTest01[0]: Still modifying... [id=46610d78-efa8-43f5-a840-3fb42e2335a5, 1m0s elapsed]
vra7_deployment.TFTest01[0]: Still modifying... [id=46610d78-efa8-43f5-a840-3fb42e2335a5, 1m10s elapsed]
vra7_deployment.TFTest01[0]: Still modifying... [id=46610d78-efa8-43f5-a840-3fb42e2335a5, 1m20s elapsed]
vra7_deployment.TFTest01[0]: Still modifying... [id=46610d78-efa8-43f5-a840-3fb42e2335a5, 1m30s elapsed]
vra7_deployment.TFTest01[0]: Still modifying... [id=46610d78-efa8-43f5-a840-3fb42e2335a5, 1m40s elapsed]
vra7_deployment.TFTest01[0]: Still modifying... [id=46610d78-efa8-43f5-a840-3fb42e2335a5, 1m50s elapsed]
vra7_deployment.TFTest01[0]: Still modifying... [id=46610d78-efa8-43f5-a840-3fb42e2335a5, 2m0s elapsed]
vra7_deployment.TFTest01[0]: Still modifying... [id=46610d78-efa8-43f5-a840-3fb42e2335a5, 2m10s elapsed]
vra7_deployment.TFTest01[0]: Modifications complete after 2m17s [id=46610d78-efa8-43f5-a840-3fb42e2335a5]

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

  1. Error
    No error, but the VM Machine state does not change, the state looks like this:

{
"version": 4,
"terraform_version": "0.12.26",
"serial": 16,
"lineage": "0062d5d7-6b32-b911-998e-47d45c63a129",
"outputs": {},
"resources": [
{
"mode": "managed",
"type": "vra7_deployment",
"name": "TFTest01",
"each": "list",
"provider": "provider.vra7",
"instances": [
{
"index_key": 0,
"schema_version": 0,
"attributes": {
"businessgroup_id": "6e21cee9-126e-4c8a-b532-b97d6778739b",
"businessgroup_name": "icds_bg",
"catalog_item_id": "8db0471f-44fd-4595-a600-8399627f7b77",
"catalog_item_name": "RHEL7.6",
"date_created": "2020-06-18T21:08:48.204Z",
"deployment_configuration": null,
"deployment_destroy": true,
"deployment_id": "3528b5af-07cd-4efc-976a-4b9a3afe226e",
"description": "test terraform deployment",
"id": "46610d78-efa8-43f5-a840-3fb42e2335a5",
"last_updated": "2020-06-19T07:13:48.517Z",
"lease_days": 20,
"lease_end": "2020-07-09T10:13:24.300Z",
"lease_start": "2020-06-18T21:08:48.190Z",
"name": "RHEL7.6-81936314",
"owners": [
"octavian.teodorescu"
],
"reasons": null,
"request_status": "SUCCESSFUL",
"resource_configuration": [
{
"cluster": 1,
"component_name": "vSphere_Machine_1",
"configuration": {
"ChangeLease": "true",
"ChangeOwner": "true",
"Component": "vSphere_Machine_1",
"CreateSnapshot": "true",
"DISK_VOLUMES.0.DISK_CAPACITY": "20",
"DISK_VOLUMES.0.DISK_INPUT_ID": "DISK_INPUT_ID1",
"DISK_VOLUMES.0.DISK_LABEL": "Hard disk 1",
"Destroy": "true",
"EXTERNAL_REFERENCE_ID": "vm-882",
"Expire": "true",
"GetExpirationReminder": "true",
"IS_COMPONENT_MACHINE": "false",
"MachineBlueprintName": "RHEL7.6",
"MachineDailyCost": "0",
"MachineDestructionDate": "2020-07-09T10:13:24.000Z",
"MachineExpirationDate": "2020-07-09T10:13:24.000Z",
"MachineGroupName": "icds_bg",
"MachineGuestOperatingSystem": "Red Hat Enterprise Linux 7 (64-bit)",
"MachineInterfaceDisplayName": "vSphere (vCenter)",
"MachineInterfaceType": "vSphere",
"MachineReservationName": "ansible-reservation",
"NETWORK_LIST.0.NETWORK_ADDRESS": "xx.xxx.9.12",
"NETWORK_LIST.0.NETWORK_MAC_ADDRESS": "00:50:56:be:78:df",
"NETWORK_LIST.0.NETWORK_NAME": "DPortGroup",
"NETWORK_LIST.0.NETWORK_NETWORK_NAME": "SLNetwork192",
"NETWORK_LIST.0.NETWORK_PROFILE": "SL Network 192",
"PowerOn": "true",
"Reconfigure": "true",
"Reprovision": "true",
"VirtualMachine.Admin.UUID": "503e5bb7-d639-8cb7-790e-52e176e43660",
"cpu": "2",
"endpointExternalReferenceId": "f65a17da-87ef-4350-a9ec-8c19ebff3790",
"ip_address": "xx.xxx.9.12",
"machineId": "e8d0b355-ffd5-4f06-9c5b-ecf9c64951d5",
"memory": "2560",
"name": "AZ0022",
"storage": "20",
"type": "Virtual"
},
"date_created": "2020-06-18T21:15:38.697Z",
"description": "",
"ip_address": "xx.xxx.9.12",
"last_updated": "2020-06-19T07:13:52.109Z",
"name": "AZ0022",
"parent_resource_id": "3528b5af-07cd-4efc-976a-4b9a3afe226e",
"request_id": "46610d78-efa8-43f5-a840-3fb42e2335a5",
"request_state": "SUCCESSFUL",
"resource_id": "9fb7ca4f-4307-40e3-9dbb-d74ac25bf213",
"resource_type": "Infrastructure.Virtual",
"status": "Off"
}
],
"tenant_id": "ICDS",
"wait_timeout": 15
},
"private": "xxxxxx=="
}
]
}
]
}

Expected behavior
Would have expected that when I have changed the State (or any of the other reboot variables) to apply these changes to the existing instance.
On the other hand, the command terraform plan, does sort allude that's not something I am controlling, ie:

      - date_created       = "2020-06-18T21:15:38.697Z" -> null
      - ip_address         = "xx.xxx.9.12" -> null
      - last_updated       = "2020-06-18T21:37:50.320Z" -> null
      - name               = "AZ0022" -> null
      - parent_resource_id = "3528b5af-07cd-4efc-976a-4b9a3afe226e" -> null
      - request_id         = "46610d78-efa8-43f5-a840-3fb42e2335a5" -> null
      - request_state      = "SUCCESSFUL" -> null
      - resource_id        = "9fb7ca4f-4307-40e3-9dbb-d74ac25bf213" -> null
      - resource_type      = "Infrastructure.Virtual" -> null
      - status             = "Off" -> null
    }
  + resource_configuration {
      + cluster            = (known after apply)
      + component_name     = "vSphere_Machine_1"
      + configuration      = {
          + "PowerOff"        = "true"
          + "PowerOn"         = "false"
          + "Status"          = "On"
          + "cpu"             = "2"
          + "custom_property" = "Terraform custom property test"
          + "memory"          = "2234"
        }
      + date_created       = (known after apply)
      + description        = (known after apply)
      + ip_address         = (known after apply)
      + last_updated       = (known after apply)
      + name               = (known after apply)
      + parent_resource_id = (known after apply)
      + request_id         = (known after apply)
      + request_state      = (known after apply)
      + resource_id        = (known after apply)
      + resource_type      = (known after apply)
      **+ status             = (known after apply)**
    }
}

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

Screenshots
Screenshot of the vRA reconfigure operation:
image

Logs
19062020-102137.log

Desktop (please complete the following information):

  • OS: Running the terraform commands on mac os (10.15.5), using vscode to edit files and github to store.

Error: Incorrect attribute value type: Inappropriate value for attribute "host": string required.

vRA 7.x version
vRealize Automation 7.6

Terraform version
v0.12.24

terraform-provider-vra7 plugin version
terraform-provider-vra7 plugin version 1.0.1

Describe the bug
Trying to use the remote_exec provisioner to execute commands post installation. When we use the examples provided in the documentation we get an error.

To Reproduce
Steps to reproduce the behavior:

  1. define the following in any maint.tf
  connection {
    host     = self.resource_configuration[*].ip_address
    user     = var.upn_username
    password = var.domain_password
    type     = "ssh"
  }
 
  provisioner "remote-exec" {
    inline = [
      "echo hello"
    ]
  }
  1. Terraform command
    terraform apply

  2. Error
    Error: Incorrect attribute value type: Inappropriate value for attribute "host":
    string required.

Expected behavior
remote command to be executed on the target

Desktop (please complete the following information):

  • OS: Windows 2016 and CentOS 7

Extra Information
If i remove the block above and just output the information the information is displayed as expected but in an array and not a single string

output "vm_name" {
  value = ["${vra7_deployment.deployment[*].resource_configuration[*].name}"]
}
 
output "vm_ip" {
  value = ["${vra7_deployment.deployment[*].resource_configuration[*].ip_address}"]
}

The issue appears to be related to the self object and the way the data is return from the data map from the provider!?

Terraform apply returns empty ip address

vRA 7.x version
7.6.0
Terraform version
0.12.6
terraform-provider-vra7 plugin version
0.4

Describe the bug
Cannot output the IP Address. IP Address is still empty after deploying the VM.

To Reproduce
Steps to reproduce the behavior:

  1. Terraform config file
resource "vra7_deployment" "vm" {
count = 1
catalog_item_name = "${var.catalog_name}"
catalog_item_id = "${var.catalog_id}"
description  = "${var.description}"
deployment_configuration = {
  _leaseDays = 6
}
resource_configuration = {
  "Machine.description" = "${var.description}"
  "Machine.cpu" = 1
  "Machine.memory" = 1024
.... (neccessary network configuration and others...) ......
  "Machine.ip_address" = ""
  "Machine.name"       = ""
  }
} 
  1. Terraform command
    terraform apply

  2. Error
    If you output the ip address, you will be able to see that no ip address is returned.
    IP Address is still empty
    "Machine.ip_address" = ""

Expected behavior
IP Address variable should have a value after deploying the VM.
"Machine.ip_address" = "10.0.0.1"

Logs
There is no reference to ip address in the logs.

Desktop:

  • OS: Windows/Red Hat.

Additional context
Machine.name appears with the correct hostname.

Show all the data in the state file that is returned from a deployment resource GET

The current implementation provides very limited information about the deployment in the state file.

I have created a PR which will give a lot more information about the deployment returned from the API
#40
For instance, if the config file has the following information:

_deployment_configuration = {
"_leaseDays" = "15"
"BPCustomProperty" = "custom deployment property"
}
resource_configuration = {
"vSphere1.cpu" = 1
"vSphere1.memory" = 1024
"vSphere1.cluster" = 2
"vSphere1.vSphere1CustomProperty" = "machine custom property"
}

The CURRENT STATE file looks something like this:

resource_configuration = [
{
"vSphere1.cpu" = 1
"vSphere1.memory" = 1024
"vSphere1._cluster" = 2
"vSphere1.vSphere1CustomProperty" = "machine custom property"
},
]

The NEW STATE, will look like this. A new resources property is added in the schema:

"resources": [
{
"component_name": "",
"properties": {},
"id": "931a1a-cba6-4ec1-9aba-35db1886",
"name": "Terraform-Simple-BP-43325908",
"type": "composition.resource.type.deployment"
},
{
"component_name": "vSphere1",
"properties": {
"ChangeLease": "true",
"ChangeOwner": "true",
"Component": "vSphere1",
"ConnectViaNativeVmrc": "true",
"ConnectViaVmrc": "true",
"CreateSnapshot": "true",
"DISK_VOLUMES.0.DISK_CAPACITY": "8",
"DISK_VOLUMES.0.DISK_INPUT_ID": "DISK_INPUT_ID1",
"DISK_VOLUMES.0.DISK_LABEL": "Hard disk 1",
"DISK_VOLUMES.1.DISK_CAPACITY": "2",
"DISK_VOLUMES.1.DISK_INPUT_ID": "DISK_INPUT_ID2",
"Destroy": "true",
"EXTERNAL_REFERENCE_ID": "vm-26",
"Expire": "true",
"IS_COMPONENT_MACHINE": "false",
"InstallTools": "true",
"MachineBlueprintName": "Terraform-Simple-BP",
"MachineCPU": "1",
"MachineDailyCost": "0",
"MachineDestructionDate": "2020-03-17T22:49:10.620Z",
"MachineExpirationDate": "2019-12-18T22:49:10.620Z",
"MachineGroupName": "Terraform-BG",
"MachineGuestOperatingSystem": "CentOS 4/5/6/7 (64-bit)",
"MachineInterfaceDisplayName": "vSphere (vCenter)",
"MachineInterfaceType": "vSphere",
"MachineMemory": "1024",
"MachineName": "Terraform-B05",
"MachineReservationName": "Terraform-reservation",
"MachineStorage": "10",
"MachineType": "Virtual",
"NETWORK_LIST.0.NETWORK_MAC_ADDRESS": "00:55:56:c6:63:6a",
"NETWORK_LIST.0.NETWORK_NAME": "dvPort-vm-1521",
"PowerOff": "true",
"Reboot": "true",
"Reconfigure": "true",
"Relocate": "true",
"Reprovision": "true",
"Reset": "true",
"Shutdown": "true",
"Suspend": "true",
"Unregister": "true",
"VirtualMachine.Admin.UUID": "502-0221-ca38-c6de-aae1d831b",
"endpointExternalReferenceId": "827cd6-9fd7-4477-bd2f-b637",
"ip_address": "20.115.100.20",
"machineId": "a11c8a-e275-4a27-b3d9-b889db1"
},
"id": "d833-fe02-4a97-8cb5-acb1b6f5",
"name": "Terraform-B0",
"type": "Infrastructure.Virtual"
},
{
"component_name": "vSphere1",
"properties": {
"ChangeLease": "true",
"ChangeOwner": "true",
"Component": "vSphere1",
"ConnectViaNativeVmrc": "true",
"ConnectViaVmrc": "true",
"CreateSnapshot": "true",
"DISK_VOLUMES.0.DISK_CAPACITY": "8",
"DISK_VOLUMES.0.DISK_INPUT_ID": "DISK_INPUT_ID1",
"DISK_VOLUMES.0.DISK_LABEL": "Hard disk 1",
"DISK_VOLUMES.1.DISK_CAPACITY": "2",
"DISK_VOLUMES.1.DISK_INPUT_ID": "DISK_INPUT_ID2",
"Destroy": "true",
"EXTERNAL_REFERENCE_ID": "vm-127",
"Expire": "true",
"IS_COMPONENT_MACHINE": "false",
"InstallTools": "true",
"MachineBlueprintName": "Terraform-Simple-BP",
"MachineCPU": "1",
"MachineDailyCost": "0",
"MachineDestructionDate": "2020-03-17T22:49:07.323Z",
"MachineExpirationDate": "2019-12-18T22:49:07.323Z",
"MachineGroupName": "Terraform-BG",
"MachineGuestOperatingSystem": "CentOS 4/5/6/7 (64-bit)",
"MachineInterfaceDisplayName": "vSphere (vCenter)",
"MachineInterfaceType": "vSphere",
"MachineMemory": "1024",
"MachineName": "Terraform-B04",
"MachineReservationName": "Terraform-reservation",
"MachineStorage": "10",
"MachineType": "Virtual",
"NETWORK_LIST.0.NETWORK_MAC_ADDRESS": "00:a0:56:b4:2a:4c",
"NETWORK_LIST.0.NETWORK_NAME": "Grp-wdc-m-vm-1521",
"PowerOff": "true",
"Reboot": "true",
"Reconfigure": "true",
"Relocate": "true",
"Reprovision": "true",
"Reset": "true",
"Shutdown": "true",
"Suspend": "true",
"Unregister": "true",
"VirtualMachine.Admin.UUID": "50d6-d760-f701-4f1f-831658d",
"endpointExternalReferenceId": "8ddd6-9fd7-4477-bd2f-84337",
"ip_address": "10.145.155.145",
"machineId": "b3b747-3852-4af1-bc96-cf71d"
},
"id": "24dcc989-7b4f-49bf-905e9239b2",
"name": "Terraform-B0004",
"type": "Infrastructure.Virtual"
}
]

I would appreciate any feedback on this.
@markpeek @cars @mcascone @GMZwinge @hobovirtual @diogoferreirasky

Terraform gets only first VM with _number_of_instances or _cluster > 1

vRA 7.x version
Version: 7.5.0 (Build: 10053500)
Terraform version
Terraform v0.12.16
terraform-provider-vra7 plugin version
provider.vra7 v0.5.0

Describe the bug
With _number_of_instances > 1 in deployment_configuration or _cluster > 1 in resource_configuration, vRealize provision the number of VM specified in _number_of_instances or _cluster under a single deployment. But Terraform gets back only the first VM in the deployment.

To Reproduce
Steps to reproduce the behavior:

  1. Terraform config file
resource "vra7_deployment" "test_deployment" {
  catalog_item_name = "<catalogName>"
  deployment_configuration = {
    # Same with this instead of _cluster below.
    #_number_of_instances = "2"
  }
  resource_configuration = {
    "vSphere__vCenter__Machine_1._cluster" = "2"
    "vSphere__vCenter__Machine_1.name" = ""
  }
}
output "resource_configuration" {
  value = vra7_deployment.test_deployment[*].resource_configuration
}
  1. Terraform command
    terraform init
    terraform apply
  2. Error
    The file terraform.tfstate contains info only on the first VM.
    The output lists info only for the first VM:
resource_configuration = [
  {
    "vSphere__vCenter__Machine_1._cluster" = "2"
    "vSphere__vCenter__Machine_1.name" = "<machine1Name>"
  },
]

Expected behavior

  • terraform.tfstate file should contain info on all the VMs in the deployment.
  • Output should list info for all the VMs in the deployment. Eg:
resource_configuration = [
  {
    "vSphere__vCenter__Machine_1._cluster" = "2"
    "vSphere__vCenter__Machine_1.name" = "<machine1Name>"
  },
  {
    "vSphere__vCenter__Machine_1._cluster" = "2"
    "vSphere__vCenter__Machine_1.name" = "<machine2Name>"
  },
]

Screenshots
If applicable, add screenshots to help explain your problem.

Logs
Attach logs to help debug the issue

  1. Attached vra-terraform-scrubed.log.
  2. Attached Terraform console log enabled for trace console-scrubed.log (Enable terraform logs following the steps mentioned in https://www.terraform.io/docs/configuration/environment-variables.html)
    The vra-terraform.log and the Terraform console log both correctly show the name and IP address for all the VMs, not just the first one. Search for The resource data map of the resource vSphere__vCenter__Machine_1 is.

Desktop (please complete the following information):

  • OS: Windows 10, version 1703

terraform apply always results in change despite not change to .tf

vRA 7.x version
7.6
Terraform version
Terraform v0.12.18
terraform-provider-vra7 plugin version

  • provider.vra7 v1.0.0

Describe the bug
After upgrading to vra7 provider v1.0.0, I noticed executing terraform apply multiple times in a row results in a change, when nothing has been changed.

To Reproduce
provider "vra7" {
tenant = "acme"
host = "https://xxxx.xxxx.com"
insecure = "true"
}
resource "vra7_deployment" "myDeployment" {
count = 1
catalog_item_name = "bp_acme_develop"
businessgroup_name = "bizgroup1"
description = "Test Terraform deployment"
reasons = "Testing the vRA 7 Terraform plugin"
resource_configuration {
component_name = "vm"
cluster = 2
configuration = {}
}
}

Run "terraform apply"
get "Resources: 1 added, 0 changed, 0 destroyed."
Run "terraform apply" again
get "Resources: 0 added, 1 changed, 0 destroyed."
where it Null's out all the resources and then reapplies them all exactly the same.

Expected behavior
"Resources: 0 added, 0 changed, 0 destroyed."
on subsequent "terraform apply" with no change to the .tf file

Screenshots
If applicable, add screenshots to help explain your problem.

Logs
Attach logs to help debug the issue

  1. Attach vra-terraform.log
  2. Attach Terraform console log (Enable terraform logs following the steps mentioned in https://www.terraform.io/docs/configuration/environment-variables.html)
  3. crash.log(if any)

Desktop (please complete the following information):

  • OS: [e.g. iOS]

Additional context
Add any other context about the problem here.

vRA Windows machine creation does not return host name/addr before moving to provisioner block

vRA 7.x version
vRA 7.0.1 3621464
Terraform version
Terraform v0.11.13
terraform-provider-vra7 plugin version
provider.vra7 v0.2.0

Describe the bug
When creating a Windows machine in vRA, Terraform will move on to the Provisioner block before it has acquired the IP/FQDN of the new machine to pass into the provisioner.

To Reproduce
Steps to reproduce the behavior:

hello.tf

resource "vra7_deployment" "terraform-1" {
  count             = "${var.server_count}"
  description       = "deployment via terraform"
  reasons           = "because it's awesome"
  catalog_item_name = "${var.vra_cat_item_name}"
  wait_timeout      = "1800"

  provisioner "chef" {
    # This is for chef_server to talk to the node
    connection {
      type = "winrm"
      user = "${var.KT_USER}"
      password = "${var.KT_PASS}"
      insecure = true
    }
    
    # This is for TF to talk to the chef_server
    server_url = "${var.chef_server_url}" 
    node_name  = "terraform-chef-test"
    run_list   = [ ]
    user_name  = "${var.chef_user_name}"
    user_key   = "${file(var.chef_user_pem)}"
    recreate_client = true
    fetch_chef_certificates = true
    environment = "_default"
    ssl_verify_mode = false
    version = "12"
  }
}
  1. Terraform command
    terraform apply -auto-approve

  2. Error

vra7_deployment.terraform-1: Still creating... (21m20s elapsed)
vra7_deployment.terraform-1 (chef): Connecting to remote host via WinRM...
vra7_deployment.terraform-1 (chef):   Host:
vra7_deployment.terraform-1 (chef):   Port: 5985
vra7_deployment.terraform-1 (chef):   User: engineering
vra7_deployment.terraform-1 (chef):   Password: true
vra7_deployment.terraform-1 (chef):   HTTPS: false
vra7_deployment.terraform-1 (chef):   Insecure: true
vra7_deployment.terraform-1 (chef):   NTLM: false
vra7_deployment.terraform-1 (chef):   CACert: false

* vra7_deployment.terraform-1: interrupted - last error: unknown error Post http://:5985/wsman: dial tcp :5985: connectex: No connection could be made because the target machine actively refused it.

Expected behavior
The block's provisioner successfully connects to the new machine and provisions it.

Screenshots
provided in snippets above

Logs
Attach logs to help debug the issue

  1. Attach vra-terraform.log
    Sorry i am figuring out how to do this, i will provide later if necessary
  2. Attach Terraform console log (Enable terraform logs following the steps mentioned in https://www.terraform.io/docs/configuration/environment-variables.html)
  3. crash.log(if any)

Desktop (please complete the following information):

  • OS: Windows 10

Additional context
Thank you!!

resource_configuration confusion when updating to TF 0.12

vRA 7.x version
vRA 7.0.1
Terraform version

Terraform v0.12.7
+ provider.vra7 v0.4.1

Describe the bug
after upgrade to TF v0.12, my resource_configuration block fails:

  resource_configuration = {
    vSphere_Machine_1.name        = ""
    vSphere_Machine_1.ip_address  = ""
    vSphere_Machine_1.description = "Terraform Machine ${count.index + 1}"
  }
> terraform validate
Error: Reference to undeclared resource

  on main.tf line 26, in resource "vra7_deployment" "TF-Deploy":
  26:     vSphere_Machine_1.description = "Terraform Machine ${count.index + 1}"

A managed resource "vSphere_Machine_1" "description" has not been declared in
the root module.

This happens for all three parameters in the block.

To Reproduce
Steps to reproduce the behavior:

  1. Terraform config file
  2. Terraform command
  3. Error

Expected behavior
resource_configuration should pass validation.

Screenshots
If applicable, add screenshots to help explain your problem.

Logs
Attach logs to help debug the issue

  1. Attach vra-terraform.log
  2. Attach Terraform console log (Enable terraform logs following the steps mentioned in https://www.terraform.io/docs/configuration/environment-variables.html)
  3. crash.log(if any)

Desktop (please complete the following information):

  • OS: [e.g. iOS]

Additional context
This works fine under TF v0.11. The v0.12upgrade helper script updated the resource_configuration block to add the = :

 resource_configuration = {
    vSphere_Machine_1.name        = ""
    vSphere_Machine_1.ip_address  = ""
    vSphere_Machine_1.description = "Terraform Machine ${count.index + 1}"
  }

but then gets the error shown above.
Removing the = doesn't work. I tried putting the left-side parameters in quotes, but that causes other problems, i don't think that's the issue.

IPAddress return is empty with latest release of vRealize Automation

vRA 7.x version
vRealize Automation 7.6.0

Terraform version
Terraform v0.11.13

terraform-provider-vra7 plugin version
provider.vra7 v0.2.0

Describe the bug
Following issue #136

After some investigation following an upgrade from vRealize 7.4 to 7.6 me and one of my customer, we realized that the ip_address data is no longer populated in the resourceViews only if the user who made the request has the Tenant Administrator role in vRealize Automation.

Looking into resourceViews, seems that the NETWORK_LIST data map, always contains the IP no matter who made the request or it's role(s)

"NETWORK_LIST": [
  {
    "componentTypeId": "com.vmware.csp.component.iaas.proxy.provider",
    "componentId": null,
    "classId": "dynamicops.api.model.NetworkViewModel",
    "typeFilter": null,
    "data": {
      "NETWORK_ADDRESS": "10.10.10.102",
      "NETWORK_MAC_ADDRESS": "00:50:56:a6:30:fa",
      "NETWORK_NAME": "vxw-dvs-24-universalwire-1-sid-10000-mgmt-10.10.10.0-24",
      "NETWORK_NETWORK_NAME": "mgmt",
      "NETWORK_PROFILE": "mgmt"
    }
  }
]

Should we change the IPAddress or add a new NetworkAddress resource in the vra7_sdk.go to reflect this behavior change in the latest vRA version?

To Reproduce
Steps to reproduce the behavior:

  1. Create a user with Tenant Administrator in vRA

  2. Launch deployment via terraform config file

    Add the IPAddress output

    output "vm1 IP Address" {
       value = "${vra7_deployment.deployment1.resource_configuration.vm1.ip_address}"
    }
    

    2.1 You should get the following output
    vm1 IP Address =

  3. Repeat the same steps with a user that doesn't have the Tenant Administor role
    3.1 You should get the following output
    vm1 IP Address = 10.10.10.X

Desktop (please complete the following information):

  • OS: centOS 7.5

The provider does not wait for the terminal state of the update/destroy requests and returns pre-maturely when the request is still in progress in vRA

vRA 7.x version
7.5
Describe the bug
While updating or destroying, the provider is not waiting for the status of the request and returning successfully even if the request is still in progress in vRA.
To Reproduce
Steps to reproduce the behavior:

  1. Terraform config file
    `resource "vra7_deployment" "my_vra7_deployment" {
    catalog_item_name = "requestid test"
    description = "Test deployment"
    reasons = "Testing the vRA 7 Terraform plugin"

    deployment_configuration = {
    _leaseDays = "15"
    deployment_property = "custom deployment property"
    }
    resource_configuration = {
    "vSphereVM1.cpu" = 1
    "vSphereVM1.memory" = 2048
    "vSphereVM1.machine_property" = "machine custom property"
    }
    wait_timeout = 1
    businessgroup_name = "Development"
    }`

  2. terraform apply

  3. VM provisioned

  4. Change memory to 1024

  5. terraform apply

  6. Provider returns successfully while the request is still in progress in vRA

Expected behavior
The provider should wait for the terminal state or timeout

Additional context
This has been observed when the request ends up with successful state.

Provider 1.0.0 - Required to specify all values even if there's a default specified in the blueprint

vRA 7.x version
vRealize Automation 7.6

Terraform version
v0.12.24

terraform-provider-vra7 plugin version
The terraform-provider-vra7 plugin version 1.0.0

Describe the bug
New behavior in the latest provider, when deploying a blueprint, we need to declare a bunch of new values that were previously optional.

Example, lease_days, before 1.0.0 we could just use the default value (which was the minimal value defined in the blueprint) and same thing for the cluster (instance number of a component)

To Reproduce
Steps to reproduce the behavior:

  1. maint.tf content
provider "vra7" {
    username = var.vra_username
    password = var.vra_password
    tenant = var.vra_tenant
    host = var.vra_host
    insecure = true
}

resource "vra7_deployment" "deployment" {
  businessgroup_name = "dev"
  catalog_item_name = "dev vm"              
  reasons = "provide a reason"
  description = "provide a description"
  //lease_days = 2

  resource_configuration {
    component_name = "vm1"
    //cluster = 1

    //Please Provide the following information for the bootstrap node component
    configuration = {
      "custom.midname" = "BASE"
    }
  } 
}
  1. Terraform command
    terraform apply

  2. Error
    Error: The catalog item qequest failed with error vRealize API: [{Code:20117 Mes
    sage:The data specified within the request is invalid. SystemMessage:The data sp
    ecified within the request is invalid.} {Code:11002 Message:The value of the '_c
    luster' field cannot be less than 1. SystemMessage:The value of the field with i
    d _cluster cannot be less than 1.} {Code:11002 Message:The value of the '_leaseD
    ays' field cannot be less than 2. SystemMessage:The value of the field with id _
    leaseDays cannot be less than 2.} {Code:400 Message: SystemMessage:}]

on main.tf line 9, in resource "vra7_deployment" "deployment":
9: resource "vra7_deployment" "deployment" {

Expected behavior
Don't declare property value when default exist in the blueprint

Desktop (please complete the following information):

  • OS: Windows 2016 and CentOS 7

PS: typo highlighted in bold for the error message, i guess this sould mention request instead of qequest :D

Scale out/in not working due to drift in Terraform state file

vRA 7.x version
vRA 7.6 HF 7
Terraform version
Terraform v0.12.18
terraform-provider-vra7 plugin version
provider.vra7 v2.0.1

Describe the bug

Following scenarios of scale out/in are not working as expected with the Terraform provider for VMware vRealize Automation 7 version 2.0.1 due to disparities between vRA state and Terraform state.

Scale out VM count
Scale in from original VM count
Scale in from scaled-out VM count
Reconfigure the scaled-up VMs (hot add CPU/memory)

To Reproduce
This is mainly happening due to scaled out VM details are not storing in the Terraform state.

Expected behavior
Scaled out VM details should in the Terraform state accurately.

Wrong IP/FQDN from vRa given to Chef provisioner

vRA 7.x version
7.0.1
Terraform version
Terraform v0.11.14
terraform-provider-vra7 plugin version
provider.vra7 v0.2.0

Describe the bug
When running Terraform to create a vRA VM and then provision it with Chef, Terraform gets the correct IP and FQDN from vRA, but somehow is passing an incorrect IP or FQDN (not sure which) to the Chef provisioner.
What results is a Chef run on an unintended machine.
Terraform does not seem to have any knowledge of the incorrect data in its logs, and it outputs correct information. So i have no idea how the incorrect data is getting injected into the flow.

To Reproduce
Steps to reproduce the behavior:

  1. Terraform config file
    main.tf.txt
  2. Terraform command
    terraform apply
  3. Error
Apply complete! Resources: 1 added, 0 changed, 1 destroyed.

Outputs:

ip addrs = [
    10.12.235.76
]
machines = [
    MTPCTSCID139
]
run_list = role[ice-remote-uat]
~\Documents\github\Terraform-base [master ≡ +1 ~3 -0 !]> knife node show terraform-chef-test-1
Node Name:   terraform-chef-test-1
Environment: _default
FQDN:        MTPCTSCID422.consilio.com
IP:          10.12.235.82
Run List:    role[ice-remote-uat]

Expected behavior
The IP and FQDN discovered by Terraform are passed to the chef provider correctly.

Screenshots
n/a

Logs
Attach logs to help debug the issue

  1. vra-terraform.log
  2. Attach Terraform console log (Enable terraform logs following the steps mentioned in https://www.terraform.io/docs/configuration/environment-variables.html)
  3. crash.log(if any)

Desktop (please complete the following information):

  • OS: Windows 10

Additional context
I had a similar problem previously with the FQDN not being discovered, and resolved it by putting a blank fqdn variable in the provisioner block:

resource_configuration {
   vSphere_Machine_1.name = ""
}

And it was working perfectly until recently.

EOF in /identity/api/tokens when creating multiple resources

General version information:

  • vRA 7.6
  • Terraform version 0.13.0
  • Terraform-provider-vra7 plugin version 1.0.2

Describe the bug
It looks like the VRA provider is not able to create multiple resources in the same terraform run.
I have three resources defined in the file and only 1 of them completes successfully.
The following error is printed in the logs:

2020-08-19T21:21:27.07+02:00 vra7_client.go:53 DoRequest ▶ ERRO 0a6 An error occurred when calling POST on https://skylab.windesheim.nl/identity/api/tokens. Error: Post "https://skylab.windesheim.nl/identity/api/tokens": EOF

The following message is the error printed in the terminal:

Error: The catalog item request failed with error Post "https://skylab.windesheim.nl/identity/api/tokens": EOF

  on Terraform-dev-VRA.tf line 12, in resource "vra7_deployment" "vmware-mgmt":
  12: resource "vra7_deployment" "vmware-mgmt" {

Error: Post "https://skylab.windesheim.nl/identity/api/tokens": http: server closed idle connection

  on Terraform-dev-VRA.tf line 33, in resource "vra7_deployment" "vmware-storage":
  33: resource "vra7_deployment" "vmware-storage" {

To Reproduce
Steps to reproduce the behavior:

  1. Terraform config file
    The terraform config is defined as follows:

provider "vra7" {
  username = var.username
  password = var.password
  tenant   = var.tenant
  host     = var.host
  insecure = var.insecure
  version  = "~> 1.0.2"
}

# Machine 1 Master01
resource "vra7_deployment" "vmware-mgmt" {
  catalog_item_name = var.catalog_item_name
  businessgroup_id  = "c76fc185-3c56-466c-acd6-c423c5a0e03e"
  description       = var.description
  count             = 1
  lease_days        = 160



  resource_configuration {
    component_name = "ESXi6.7"
    cluster        = 4
    configuration = {
      cpu                          = 8
      memory                       = 16384
      "VirtualMachine.Network0.Name"  = "vxw-dvs-24323-virtualwire-3-sid-5002-studentnet0-pLab-s1093026"
      "VirtualMachine.Network1.Name"  = "vxw-dvs-24323-virtualwire-20-sid-5013-studentnet1-pLab-s1093026"
      "VirtualMachine.Network2.Name"  = "vxw-dvs-24323-virtualwire-21-sid-5003-studentnet2-pLab-s1093026"
    }
  }
}
resource "vra7_deployment" "vmware-storage" {
  catalog_item_name = var.catalog_item_name2
  businessgroup_id  = "c76fc185-3c56-466c-acd6-c423c5a0e03e"
  description       = var.storage_description
  count             = 1
  lease_days        = 160


  resource_configuration {
    component_name = "OpenMediaVault"
    cluster        = 1
    configuration = {
      cpu                          = 2
      memory                       = 4096
      "VirtualMachine.Network0.Name"  = "vxw-dvs-24323-virtualwire-3-sid-5002-studentnet0-pLab-s1093026"
      "VirtualMachine.Network1.Name"  = "vxw-dvs-24323-virtualwire-20-sid-5013-studentnet1-pLab-s1093026"

    }
  }

}

resource "vra7_deployment" "vmware-worker" {
  catalog_item_name = var.catalog_item_name
  businessgroup_id  = "c76fc185-3c56-466c-acd6-c423c5a0e03e"
  description       = var.worker_description
  count             = 1
  lease_days        = 160



  resource_configuration {
    component_name = "ESXi6.7"
    cluster        = 4
    configuration = {
      cpu                          = 2
      memory                       = 16384
      "VirtualMachine.Network0.Name"  = "vxw-dvs-24323-virtualwire-3-sid-5002-studentnet0-pLab-s1093026"
      "VirtualMachine.Network1.Name"  = "vxw-dvs-24323-virtualwire-20-sid-5013-studentnet1-pLab-s1093026"
      "VirtualMachine.Network2.Name"  = "vxw-dvs-24323-virtualwire-21-sid-5003-studentnet2-pLab-s1093026"

    }
  }
}
  1. Terraform command
    terraform apply
  2. Error

Expected behavior
The resources will be deployed without any errors based on the defined configuration.

terraform apply
Screenshots
If applicable, add screenshots to help explain your problem.

Logs
Attach logs to help debug the issue

  1. Attach vra-terraform.log
2020-08-19T21:21:13.547+02:00 vra7_client.go:56 DoRequest ▶ INFO 001 Check the status of the request https://skylab.windesheim.nl/identity/api/tokens 
 The response is: 200
2020-08-19T21:21:26.278+02:00 vra7_client.go:56 DoRequest ▶ INFO 001 Check the status of the request https://skylab.windesheim.nl/identity/api/tokens 
 The response is: 200
2020-08-19T21:21:26.284+02:00 resource_vra7_deployment.go:153 resourceVra7DeploymentCreate ▶ INFO 002 Creating the resource vra7_deployment...
2020-08-19T21:21:26.284+02:00 resource_vra7_deployment.go:153 resourceVra7DeploymentCreate ▶ INFO 003 Creating the resource vra7_deployment...
2020-08-19T21:21:26.284+02:00 resource_vra7_deployment.go:153 resourceVra7DeploymentCreate ▶ INFO 004 Creating the resource vra7_deployment...
2020-08-19T21:21:26.284+02:00 resource_vra7_deployment.go:595 readProviderConfiguration ▶ INFO 005 Reading the provider configuration data.....
2020-08-19T21:21:26.285+02:00 resource_vra7_deployment.go:595 readProviderConfiguration ▶ INFO 007 Reading the provider configuration data.....
2020-08-19T21:21:26.285+02:00 resource_vra7_deployment.go:595 readProviderConfiguration ▶ INFO 006 Reading the provider configuration data.....
2020-08-19T21:21:26.406+02:00 vra7_client.go:56 DoRequest ▶ INFO 008 Check the status of the request https://skylab.windesheim.nl/identity/api/tokens 
 The response is: 200
2020-08-19T21:21:26.419+02:00 vra7_client.go:56 DoRequest ▶ INFO 009 Check the status of the request https://skylab.windesheim.nl/identity/api/tokens 
 The response is: 200
2020-08-19T21:21:26.421+02:00 vra7_client.go:56 DoRequest ▶ INFO 00a Check the status of the request https://skylab.windesheim.nl/identity/api/tokens 
 The response is: 200
2020-08-19T21:21:26.499+02:00 vra7_client.go:56 DoRequest ▶ INFO 00b Check the status of the request https://skylab.windesheim.nl/catalog-service/api/consumer/entitledCatalogItemViews?page=1 
 The response is: 200
2020-08-19T21:21:26.535+02:00 vra7_client.go:56 DoRequest ▶ INFO 00c Check the status of the request https://skylab.windesheim.nl/catalog-service/api/consumer/entitledCatalogItemViews?page=1 
 The response is: 200
2020-08-19T21:21:26.555+02:00 vra7_client.go:56 DoRequest ▶ INFO 00d Check the status of the request https://skylab.windesheim.nl/identity/api/tokens 
 The response is: 200
2020-08-19T21:21:26.609+02:00 vra7_client.go:56 DoRequest ▶ INFO 00e Check the status of the request https://skylab.windesheim.nl/identity/api/tokens 
 The response is: 200
2020-08-19T21:21:26.651+02:00 vra7_client.go:56 DoRequest ▶ INFO 00f Check the status of the request https://skylab.windesheim.nl/catalog-service/api/consumer/entitledCatalogItemViews?page=1 
 The response is: 200
2020-08-19T21:21:26.651+02:00 resource_vra7_deployment.go:629 readProviderConfiguration ▶ INFO 010 The values provided in the TF config file is: 
 {ESXi 6.7 43e5dc20-6d31-4493-8393-9670a1de865e Vmware Workers  c76fc185-3c56-466c-acd6-c423c5a0e03e  900  map[] true 160  [{ESXi6.7 4        map[VirtualMachine.Network0.Name:vxw-dvs-24323-virtualwire-3-sid-5002-studentnet0-pLab-s1093026 VirtualMachine.Network1.Name:vxw-dvs-24323-virtualwire-20-sid-5013-studentnet1-pLab-s1093026 VirtualMachine.Network2.Name:vxw-dvs-24323-virtualwire-21-sid-5003-studentnet2-pLab-s1093026 cpu:2 memory:16384]    }]} 
2020-08-19T21:21:26.651+02:00 resource_vra7_deployment.go:532 checkResourceConfigValidity ▶ INFO 011 Checking if the terraform config file is valid
2020-08-19T21:21:26.699+02:00 vra7_client.go:56 DoRequest ▶ INFO 012 Check the status of the request https://skylab.windesheim.nl/catalog-service/api/consumer/entitledCatalogItemViews?page=1 
 The response is: 200
2020-08-19T21:21:26.752+02:00 vra7_client.go:53 DoRequest ▶ ERRO 013 An error occurred when calling POST on https://skylab.windesheim.nl/identity/api/tokens. Error: Post "https://skylab.windesheim.nl/identity/api/tokens": http: server closed idle connection
2020-08-19T21:21:26.752+02:00 vra7_client.go:56 DoRequest ▶ INFO 014 Check the status of the request https://skylab.windesheim.nl/catalog-service/api/consumer/entitledCatalogItemViews?page=1 
 The response is: 200
2020-08-19T21:21:26.752+02:00 resource_vra7_deployment.go:629 readProviderConfiguration ▶ INFO 015 The values provided in the TF config file is: 
 {ESXi 6.7 43e5dc20-6d31-4493-8393-9670a1de865e Vmware Management  c76fc185-3c56-466c-acd6-c423c5a0e03e  900  map[] true 160  [{ESXi6.7 4        map[VirtualMachine.Network0.Name:vxw-dvs-24323-virtualwire-3-sid-5002-studentnet0-pLab-s1093026 VirtualMachine.Network1.Name:vxw-dvs-24323-virtualwire-20-sid-5013-studentnet1-pLab-s1093026 VirtualMachine.Network2.Name:vxw-dvs-24323-virtualwire-21-sid-5003-studentnet2-pLab-s1093026 cpu:8 memory:16384]    }]} 
2020-08-19T21:21:26.753+02:00 resource_vra7_deployment.go:532 checkResourceConfigValidity ▶ INFO 016 Checking if the terraform config file is valid
2020-08-19T21:21:26.774+02:00 vra7_client.go:56 DoRequest ▶ INFO 017 Check the status of the request https://skylab.windesheim.nl/identity/api/tokens 
 The response is: 200
2020-08-19T21:21:26.848+02:00 vra7_client.go:56 DoRequest ▶ INFO 018 Check the status of the request https://skylab.windesheim.nl/identity/api/tokens 
 The response is: 200
2020-08-19T21:21:26.999+02:00 vra7_client.go:56 DoRequest ▶ INFO 019 Check the status of the request https://skylab.windesheim.nl/catalog-service/api/consumer/entitledCatalogItems/43e5dc20-6d31-4493-8393-9670a1de865e/requests/template 
 The response is: 200
2020-08-19T21:21:26.999+02:00 resource_vra7_deployment.go:539 checkResourceConfigValidity ▶ INFO 01a The request template data corresponding to the catalog item 43e5dc20-6d31-4493-8393-9670a1de865e is: 
 map[ESXi6.7:map[classId:Blueprint.Component.Declaration componentId:<nil> componentTypeId:com.vmware.csp.component.cafe.composition data:map[VMware.Network.Type:VMXNET3 VirtualMachine.Network0.Name:1 - Default First Network - No Network Access _cluster:1 _hasChildren:false cpu:1 datacenter_location:<nil> description:ESXi 6.7 disks:[map[classId:Infrastructure.Compute.Machine.MachineDisk componentId:<nil> componentTypeId:com.vmware.csp.iaas.blueprint.service data:map[capacity:8 custom_properties:<nil> id:1.565897201288e+12 initial_location: is_clone:true label:Hard disk 1 storage_reservation_policy: userCreated:false volumeId:0] typeFilter:<nil>]] display_location:false guest_customization_specification:<nil> machine_prefix:<nil> max_network_adapters:10 max_per_user:0 max_volumes:60 memory:4096 nics:[map[classId:Infrastructure.Compute.Machine.Nic componentId:<nil> componentTypeId:com.vmware.csp.iaas.blueprint.service data:map[address: assignment_type:DHCP id:0 load_balancing: network:<nil> network_profile:<nil>] typeFilter:<nil>]] os_arch:x86_64 os_distribution:<nil> os_type:Linux os_version:<nil> ovfAuthNeeded:false ovf_proxy_endpoint:<nil> ovf_url:<nil> ovf_url_pwd:<nil> ovf_url_username:<nil> ovf_use_proxy:false property_groups:<nil> reservation_policy:map[classId:Infrastructure.Reservation.Policy.ComputeResource componentId:<nil> id:RP_project_prakticum label:RP_project_prakticum] security_groups:[] security_tags:[] storage:8] typeFilter:ESXi67*ESXi6.7] _archiveDays:14 _leaseDays:160 _number_of_instances:1 _snapshot_propagation:true]
2020-08-19T21:21:26.999+02:00 resource_vra7_deployment.go:548 checkResourceConfigValidity ▶ INFO 01b The component name(s) in the blueprint corresponding to the catalog item: map[ESXi6.7:true]
2020-08-19T21:21:26.999+02:00 resource_vra7_deployment.go:195 resourceVra7DeploymentCreate ▶ INFO 05e The updated catalog item request template  is map[ESXi6.7:map[classId:Blueprint.Component.Declaration componentId:<nil> componentTypeId:com.vmware.csp.component.cafe.composition data:map[VMware.Network.Type:VMXNET3 VirtualMachine.Network0.Name:vxw-dvs-24323-virtualwire-3-sid-5002-studentnet0-pLab-s1093026 VirtualMachine.Network1.Name:vxw-dvs-24323-virtualwire-20-sid-5013-studentnet1-pLab-s1093026 VirtualMachine.Network2.Name:vxw-dvs-24323-virtualwire-21-sid-5003-studentnet2-pLab-s1093026 _cluster:4 _hasChildren:false cpu:2 datacenter_location:<nil> description:ESXi 6.7 disks:[map[classId:Infrastructure.Compute.Machine.MachineDisk componentId:<nil> componentTypeId:com.vmware.csp.iaas.blueprint.service data:map[capacity:8 custom_properties:<nil> id:1.565897201288e+12 initial_location: is_clone:true label:Hard disk 1 storage_reservation_policy: userCreated:false volumeId:0] typeFilter:<nil>]] display_location:false guest_customization_specification:<nil> machine_prefix:<nil> max_network_adapters:10 max_per_user:0 max_volumes:60 memory:16384 nics:[map[classId:Infrastructure.Compute.Machine.Nic componentId:<nil> componentTypeId:com.vmware.csp.iaas.blueprint.service data:map[address: assignment_type:DHCP id:0 load_balancing: network:<nil> network_profile:<nil>] typeFilter:<nil>]] os_arch:x86_64 os_distribution:<nil> os_type:Linux os_version:<nil> ovfAuthNeeded:false ovf_proxy_endpoint:<nil> ovf_url:<nil> ovf_url_pwd:<nil> ovf_url_username:<nil> ovf_use_proxy:false property_groups:<nil> reservation_policy:map[classId:Infrastructure.Reservation.Policy.ComputeResource componentId:<nil> id:RP_project_prakticum label:RP_project_prakticum] security_groups:[] security_tags:[] storage:8] typeFilter:ESXi67*ESXi6.7] _archiveDays:14 _leaseDays:160 _number_of_instances:1 _snapshot_propagation:true]
2020-08-19T21:21:27.042+02:00 vra7_client.go:56 DoRequest ▶ INFO 05f Check the status of the request https://skylab.windesheim.nl/catalog-service/api/consumer/entitledCatalogItems/43e5dc20-6d31-4493-8393-9670a1de865e/requests/template 
 The response is: 200
2020-08-19T21:21:27.042+02:00 resource_vra7_deployment.go:539 checkResourceConfigValidity ▶ INFO 060 The request template data corresponding to the catalog item 43e5dc20-6d31-4493-8393-9670a1de865e is: 
 map[ESXi6.7:map[classId:Blueprint.Component.Declaration componentId:<nil> componentTypeId:com.vmware.csp.component.cafe.composition data:map[VMware.Network.Type:VMXNET3 VirtualMachine.Network0.Name:1 - Default First Network - No Network Access _cluster:1 _hasChildren:false cpu:1 datacenter_location:<nil> description:ESXi 6.7 disks:[map[classId:Infrastructure.Compute.Machine.MachineDisk componentId:<nil> componentTypeId:com.vmware.csp.iaas.blueprint.service data:map[capacity:8 custom_properties:<nil> id:1.565897201288e+12 initial_location: is_clone:true label:Hard disk 1 storage_reservation_policy: userCreated:false volumeId:0] typeFilter:<nil>]] display_location:false guest_customization_specification:<nil> machine_prefix:<nil> max_network_adapters:10 max_per_user:0 max_volumes:60 memory:4096 nics:[map[classId:Infrastructure.Compute.Machine.Nic componentId:<nil> componentTypeId:com.vmware.csp.iaas.blueprint.service data:map[address: assignment_type:DHCP id:0 load_balancing: network:<nil> network_profile:<nil>] typeFilter:<nil>]] os_arch:x86_64 os_distribution:<nil> os_type:Linux os_version:<nil> ovfAuthNeeded:false ovf_proxy_endpoint:<nil> ovf_url:<nil> ovf_url_pwd:<nil> ovf_url_username:<nil> ovf_use_proxy:false property_groups:<nil> reservation_policy:map[classId:Infrastructure.Reservation.Policy.ComputeResource componentId:<nil> id:RP_project_prakticum label:RP_project_prakticum] security_groups:[] security_tags:[] storage:8] typeFilter:ESXi67*ESXi6.7] _archiveDays:14 _leaseDays:160 _number_of_instances:1 _snapshot_propagation:true]
2020-08-19T21:21:27.042+02:00 resource_vra7_deployment.go:548 checkResourceConfigValidity ▶ INFO 061 The component name(s) in the blueprint corresponding to the catalog item: map[ESXi6.7:true]
2020-08-19T21:21:27.042+02:00 resource_vra7_deployment.go:195 resourceVra7DeploymentCreate ▶ INFO 0a4 The updated catalog item request template  is map[ESXi6.7:map[classId:Blueprint.Component.Declaration componentId:<nil> componentTypeId:com.vmware.csp.component.cafe.composition data:map[VMware.Network.Type:VMXNET3 VirtualMachine.Network0.Name:vxw-dvs-24323-virtualwire-3-sid-5002-studentnet0-pLab-s1093026 VirtualMachine.Network1.Name:vxw-dvs-24323-virtualwire-20-sid-5013-studentnet1-pLab-s1093026 VirtualMachine.Network2.Name:vxw-dvs-24323-virtualwire-21-sid-5003-studentnet2-pLab-s1093026 _cluster:4 _hasChildren:false cpu:8 datacenter_location:<nil> description:ESXi 6.7 disks:[map[classId:Infrastructure.Compute.Machine.MachineDisk componentId:<nil> componentTypeId:com.vmware.csp.iaas.blueprint.service data:map[capacity:8 custom_properties:<nil> id:1.565897201288e+12 initial_location: is_clone:true label:Hard disk 1 storage_reservation_policy: userCreated:false volumeId:0] typeFilter:<nil>]] display_location:false guest_customization_specification:<nil> machine_prefix:<nil> max_network_adapters:10 max_per_user:0 max_volumes:60 memory:16384 nics:[map[classId:Infrastructure.Compute.Machine.Nic componentId:<nil> componentTypeId:com.vmware.csp.iaas.blueprint.service data:map[address: assignment_type:DHCP id:0 load_balancing: network:<nil> network_profile:<nil>] typeFilter:<nil>]] os_arch:x86_64 os_distribution:<nil> os_type:Linux os_version:<nil> ovfAuthNeeded:false ovf_proxy_endpoint:<nil> ovf_url:<nil> ovf_url_pwd:<nil> ovf_url_username:<nil> ovf_use_proxy:false property_groups:<nil> reservation_policy:map[classId:Infrastructure.Reservation.Policy.ComputeResource componentId:<nil> id:RP_project_prakticum label:RP_project_prakticum] security_groups:[] security_tags:[] storage:8] typeFilter:ESXi67*ESXi6.7] _archiveDays:14 _leaseDays:160 _number_of_instances:1 _snapshot_propagation:true]
2020-08-19T21:21:27.07+02:00 vra7_client.go:56 DoRequest ▶ INFO 0a5 Check the status of the request https://skylab.windesheim.nl/identity/api/tokens 
 The response is: 200
2020-08-19T21:21:27.07+02:00 vra7_client.go:53 DoRequest ▶ ERRO 0a6 An error occurred when calling POST on https://skylab.windesheim.nl/identity/api/tokens. Error: Post "https://skylab.windesheim.nl/identity/api/tokens": EOF
2020-08-19T21:21:27.547+02:00 vra7_client.go:56 DoRequest ▶ INFO 0a7 Check the status of the request https://skylab.windesheim.nl/catalog-service/api/consumer/entitledCatalogItems/43e5dc20-6d31-4493-8393-9670a1de865e/requests 
 The response is: 201
2020-08-19T21:21:27.548+02:00 resource_vra7_deployment.go:640 waitForRequestCompletion ▶ INFO 0a8 Waiting for 30 seconds before checking request status.
2020-08-19T21:21:57.618+02:00 vra7_client.go:56 DoRequest ▶ INFO 0a9 Check the status of the request https://skylab.windesheim.nl/identity/api/tokens 
 The response is: 200
2020-08-19T21:21:57.73+02:00 vra7_client.go:56 DoRequest ▶ INFO 0aa Check the status of the request https://skylab.windesheim.nl/catalog-service/api/consumer/requests/8ccfd51d-2b47-4d81-9fab-324e8d35230f 
 The response is: 200
2020-08-19T21:21:57.73+02:00 resource_vra7_deployment.go:645 waitForRequestCompletion ▶ INFO 0ab Checking to see the status of the request. Status: IN_PROGRESS.
2020-08-19T21:21:57.73+02:00 resource_vra7_deployment.go:652 waitForRequestCompletion ▶ INFO 0ac The request is still IN PROGRESS.
2020-08-19T21:21:57.73+02:00 resource_vra7_deployment.go:640 waitForRequestCompletion ▶ INFO 0ad Waiting for 30 seconds before checking request status.
2020-08-19T21:22:27.858+02:00 vra7_client.go:56 DoRequest ▶ INFO 0ae Check the status of the request https://skylab.windesheim.nl/identity/api/tokens 
 The response is: 200
2020-08-19T21:22:27.928+02:00 vra7_client.go:56 DoRequest ▶ INFO 0af Check the status of the request https://skylab.windesheim.nl/catalog-service/api/consumer/requests/8ccfd51d-2b47-4d81-9fab-324e8d35230f 
 The response is: 200
2020-08-19T21:22:27.929+02:00 resource_vra7_deployment.go:645 waitForRequestCompletion ▶ INFO 0b0 Checking to see the status of the request. Status: IN_PROGRESS.
2020-08-19T21:22:27.929+02:00 resource_vra7_deployment.go:652 waitForRequestCompletion ▶ INFO 0b1 The request is still IN PROGRESS.
2020-08-19T21:22:27.929+02:00 resource_vra7_deployment.go:640 waitForRequestCompletion ▶ INFO 0b2 Waiting for 30 seconds before checking request status.
2020-08-19T21:22:58.052+02:00 vra7_client.go:56 DoRequest ▶ INFO 0b3 Check the status of the request https://skylab.windesheim.nl/identity/api/tokens 
 The response is: 200
2020-08-19T21:22:58.151+02:00 vra7_client.go:56 DoRequest ▶ INFO 0b4 Check the status of the request https://skylab.windesheim.nl/catalog-service/api/consumer/requests/8ccfd51d-2b47-4d81-9fab-324e8d35230f 
 The response is: 200
2020-08-19T21:22:58.152+02:00 resource_vra7_deployment.go:645 waitForRequestCompletion ▶ INFO 0b5 Checking to see the status of the request. Status: IN_PROGRESS.
2020-08-19T21:22:58.152+02:00 resource_vra7_deployment.go:652 waitForRequestCompletion ▶ INFO 0b6 The request is still IN PROGRESS.
2020-08-19T21:22:58.152+02:00 resource_vra7_deployment.go:640 waitForRequestCompletion ▶ INFO 0b7 Waiting for 30 seconds before checking request status.
2020-08-19T21:23:28.301+02:00 vra7_client.go:56 DoRequest ▶ INFO 0b8 Check the status of the request https://skylab.windesheim.nl/identity/api/tokens 
 The response is: 200
2020-08-19T21:23:28.374+02:00 vra7_client.go:56 DoRequest ▶ INFO 0b9 Check the status of the request https://skylab.windesheim.nl/catalog-service/api/consumer/requests/8ccfd51d-2b47-4d81-9fab-324e8d35230f 
 The response is: 200
2020-08-19T21:23:28.374+02:00 resource_vra7_deployment.go:645 waitForRequestCompletion ▶ INFO 0ba Checking to see the status of the request. Status: IN_PROGRESS.
2020-08-19T21:23:28.374+02:00 resource_vra7_deployment.go:652 waitForRequestCompletion ▶ INFO 0bb The request is still IN PROGRESS.
2020-08-19T21:23:28.374+02:00 resource_vra7_deployment.go:640 waitForRequestCompletion ▶ INFO 0bc Waiting for 30 seconds before checking request status.
2020-08-19T21:23:58.497+02:00 vra7_client.go:56 DoRequest ▶ INFO 0bd Check the status of the request https://skylab.windesheim.nl/identity/api/tokens 
 The response is: 200
2020-08-19T21:23:58.569+02:00 vra7_client.go:56 DoRequest ▶ INFO 0be Check the status of the request https://skylab.windesheim.nl/catalog-service/api/consumer/requests/8ccfd51d-2b47-4d81-9fab-324e8d35230f 
 The response is: 200
2020-08-19T21:23:58.569+02:00 resource_vra7_deployment.go:645 waitForRequestCompletion ▶ INFO 0bf Checking to see the status of the request. Status: IN_PROGRESS.
2020-08-19T21:23:58.569+02:00 resource_vra7_deployment.go:652 waitForRequestCompletion ▶ INFO 0c0 The request is still IN PROGRESS.
2020-08-19T21:23:58.57+02:00 resource_vra7_deployment.go:640 waitForRequestCompletion ▶ INFO 0c1 Waiting for 30 seconds before checking request status.
2020-08-19T21:24:28.703+02:00 vra7_client.go:56 DoRequest ▶ INFO 0c2 Check the status of the request https://skylab.windesheim.nl/identity/api/tokens 
 The response is: 200
2020-08-19T21:24:28.854+02:00 vra7_client.go:56 DoRequest ▶ INFO 0c3 Check the status of the request https://skylab.windesheim.nl/catalog-service/api/consumer/requests/8ccfd51d-2b47-4d81-9fab-324e8d35230f 
 The response is: 200
2020-08-19T21:24:28.855+02:00 resource_vra7_deployment.go:645 waitForRequestCompletion ▶ INFO 0c4 Checking to see the status of the request. Status: IN_PROGRESS.
2020-08-19T21:24:28.855+02:00 resource_vra7_deployment.go:652 waitForRequestCompletion ▶ INFO 0c5 The request is still IN PROGRESS.
2020-08-19T21:24:28.855+02:00 resource_vra7_deployment.go:640 waitForRequestCompletion ▶ INFO 0c6 Waiting for 30 seconds before checking request status.
2020-08-19T21:24:58.983+02:00 vra7_client.go:56 DoRequest ▶ INFO 0c7 Check the status of the request https://skylab.windesheim.nl/identity/api/tokens 
 The response is: 200
2020-08-19T21:24:59.052+02:00 vra7_client.go:56 DoRequest ▶ INFO 0c8 Check the status of the request https://skylab.windesheim.nl/catalog-service/api/consumer/requests/8ccfd51d-2b47-4d81-9fab-324e8d35230f 
 The response is: 200
2020-08-19T21:24:59.052+02:00 resource_vra7_deployment.go:645 waitForRequestCompletion ▶ INFO 0c9 Checking to see the status of the request. Status: IN_PROGRESS.
2020-08-19T21:24:59.052+02:00 resource_vra7_deployment.go:652 waitForRequestCompletion ▶ INFO 0ca The request is still IN PROGRESS.
2020-08-19T21:24:59.052+02:00 resource_vra7_deployment.go:640 waitForRequestCompletion ▶ INFO 0cb Waiting for 30 seconds before checking request status.
2020-08-19T21:25:29.17+02:00 vra7_client.go:56 DoRequest ▶ INFO 0cc Check the status of the request https://skylab.windesheim.nl/identity/api/tokens 
 The response is: 200
2020-08-19T21:25:29.24+02:00 vra7_client.go:56 DoRequest ▶ INFO 0cd Check the status of the request https://skylab.windesheim.nl/catalog-service/api/consumer/requests/8ccfd51d-2b47-4d81-9fab-324e8d35230f 
 The response is: 200
2020-08-19T21:25:29.241+02:00 resource_vra7_deployment.go:645 waitForRequestCompletion ▶ INFO 0ce Checking to see the status of the request. Status: IN_PROGRESS.
2020-08-19T21:25:29.241+02:00 resource_vra7_deployment.go:652 waitForRequestCompletion ▶ INFO 0cf The request is still IN PROGRESS.
2020-08-19T21:25:29.241+02:00 resource_vra7_deployment.go:640 waitForRequestCompletion ▶ INFO 0d0 Waiting for 30 seconds before checking request status.
2020-08-19T21:25:59.364+02:00 vra7_client.go:56 DoRequest ▶ INFO 0d1 Check the status of the request https://skylab.windesheim.nl/identity/api/tokens 
 The response is: 200
2020-08-19T21:25:59.432+02:00 vra7_client.go:56 DoRequest ▶ INFO 0d2 Check the status of the request https://skylab.windesheim.nl/catalog-service/api/consumer/requests/8ccfd51d-2b47-4d81-9fab-324e8d35230f 
 The response is: 200
2020-08-19T21:25:59.432+02:00 resource_vra7_deployment.go:645 waitForRequestCompletion ▶ INFO 0d3 Checking to see the status of the request. Status: IN_PROGRESS.
2020-08-19T21:25:59.432+02:00 resource_vra7_deployment.go:652 waitForRequestCompletion ▶ INFO 0d4 The request is still IN PROGRESS.
2020-08-19T21:25:59.432+02:00 resource_vra7_deployment.go:640 waitForRequestCompletion ▶ INFO 0d5 Waiting for 30 seconds before checking request status.
2020-08-19T21:26:29.8+02:00 vra7_client.go:56 DoRequest ▶ INFO 0d6 Check the status of the request https://skylab.windesheim.nl/identity/api/tokens 
 The response is: 200
2020-08-19T21:26:29.914+02:00 vra7_client.go:56 DoRequest ▶ INFO 0d7 Check the status of the request https://skylab.windesheim.nl/catalog-service/api/consumer/requests/8ccfd51d-2b47-4d81-9fab-324e8d35230f 
 The response is: 200
2020-08-19T21:26:29.914+02:00 resource_vra7_deployment.go:645 waitForRequestCompletion ▶ INFO 0d8 Checking to see the status of the request. Status: IN_PROGRESS.
2020-08-19T21:26:29.914+02:00 resource_vra7_deployment.go:652 waitForRequestCompletion ▶ INFO 0d9 The request is still IN PROGRESS.
2020-08-19T21:26:29.914+02:00 resource_vra7_deployment.go:640 waitForRequestCompletion ▶ INFO 0da Waiting for 30 seconds before checking request status.
2020-08-19T21:27:00.061+02:00 vra7_client.go:56 DoRequest ▶ INFO 0db Check the status of the request https://skylab.windesheim.nl/identity/api/tokens 
 The response is: 200
2020-08-19T21:27:00.132+02:00 vra7_client.go:56 DoRequest ▶ INFO 0dc Check the status of the request https://skylab.windesheim.nl/catalog-service/api/consumer/requests/8ccfd51d-2b47-4d81-9fab-324e8d35230f 
 The response is: 200
2020-08-19T21:27:00.132+02:00 resource_vra7_deployment.go:645 waitForRequestCompletion ▶ INFO 0dd Checking to see the status of the request. Status: SUCCESSFUL.
2020-08-19T21:27:00.132+02:00 resource_vra7_deployment.go:647 waitForRequestCompletion ▶ INFO 0de Request is SUCCESSFUL.
2020-08-19T21:27:00.133+02:00 resource_vra7_deployment.go:208 resourceVra7DeploymentCreate ▶ INFO 0df Finished creating the resource vra7_deployment with request id 8ccfd51d-2b47-4d81-9fab-324e8d35230f
2020-08-19T21:27:00.133+02:00 resource_vra7_deployment.go:389 resourceVra7DeploymentRead ▶ INFO 0e0 Reading the resource vra7_deployment with request id 8ccfd51d-2b47-4d81-9fab-324e8d35230f 
2020-08-19T21:27:00.232+02:00 vra7_client.go:56 DoRequest ▶ INFO 0e1 Check the status of the request https://skylab.windesheim.nl/identity/api/tokens 
 The response is: 200
2020-08-19T21:27:00.784+02:00 vra7_client.go:56 DoRequest ▶ INFO 0e2 Check the status of the request https://skylab.windesheim.nl/catalog-service/api/consumer/requests/8ccfd51d-2b47-4d81-9fab-324e8d35230f/resourceViews 
 The response is: 200
2020-08-19T21:27:00.786+02:00 resource_vra7_deployment.go:487 resourceVra7DeploymentRead ▶ INFO 0e3 Finished reading the resource vra7_deployment with request id 8ccfd51d-2b47-4d81-9fab-324e8d35230f
  1. Attach Terraform console log (Enable terraform logs following the steps mentioned in
    I can provide the debug logging if nessesary. I need to redact first the sentive information before i could atach it to this issue

https://www.terraform.io/docs/configuration/environment-variables.html)
3. crash.log(if any)

Desktop (please complete the following information):

  • OS: Windows 10 2004

Additional context
Add any other context about the problem here.

Description not getting updated on deployments post 2.0 upgrade.

vRA 7.x version
vRA 7.6 HF 7
Terraform version
Terraform v0.12.26
terraform-provider-vra7 plugin version
provider.vra7 v2.0.0

Describe the bug
Post 2.0 upgrade, descriptions field is not getting updated on deployemnt.

I have following resource definition

resource "vra7_deployment" "myDeployment" {
wait_timeout = "180"
count = 1
catalog_item_name = var.blueprintName
businessgroup_name = var.businessGroupVRA
description = var.jiraticket

}
To Reproduce
Do a terraform apply by passing description variable.

Expected behavior
Terraform need to update description field on vRA deployment.

terraform-provider-vra7 v0.2.0 not compatible with Terraform v0.12.0

vRA 7.x version
n/a
Terraform version
v0.12.0
terraform-provider-vra7 plugin version
v0.2.0

Describe the bug
After upgrade to Terraform 0.12, the vra7 provider can not be instantiated.

To Reproduce
Steps to reproduce the behavior:

  1. upgrade to Terraform v0.12.0
  2. terraform plan
  3. Error: Failed to instantiate provider "vra7" to obtain schema: Incompatible API version with plugin. Plugin version: 4, Client versions: [5]
  4. terraform init -upgrade
Initializing the backend...

Initializing provider plugins...
- Checking for available provider plugins...

Provider "vra7" not available for installation.

A provider named "vra7" could not be found in the Terraform Registry.

This may result from mistyping the provider name, or the given provider may
be a third-party provider that cannot be installed automatically.

In the latter case, the plugin must be installed manually by locating and
downloading a suitable distribution package and placing the plugin's executable
file in the following directory:
    terraform.d/plugins/windows_amd64

Terraform detects necessary plugins by inspecting the configuration and state.
To view the provider versions requested by each module, run
"terraform providers".

Error: no provider exists with the given name
> terraform providers
.
└── provider.vra7

Expected behavior
The vra7 provider works with the upgraded Terraform application.

Screenshots
n/a
Logs
n/a

Desktop (please complete the following information):

  • OS: Windows 10

Additional context
Thanks!

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.