### Initializing Terraform with Manually Installed Provider

Source: https://github.com/vmware/terraform-provider-vcf/blob/main/docs/install.md

This console output demonstrates the successful initialization of Terraform when a provider has been manually installed. It shows Terraform discovering and installing the local VCF provider.

```console
$ terraform init

Initializing the backend...

Initializing provider plugins...
- Finding local/vmware/vcf versions matching ">= x.y.x" ...
- Installing local/vmware/vcf x.y.x ...
- Installed local/vmware/vcf x.y.x (unauthenticated)
...

Terraform has been successfully initialized!
```

--------------------------------

### Initializing Terraform and Downloading VMware Cloud Foundation Provider

Source: https://github.com/vmware/terraform-provider-vcf/blob/main/docs/install.md

This console output demonstrates the successful execution of `terraform init`. It shows Terraform finding and installing the `vmware/vcf` provider from the registry, confirming that the configuration block is correctly set up for automated provider download.

```Console
$ terraform init

Initializing the backend...

Initializing provider plugins...
- Finding vmware/vcf versions matching ">= x.y.z" ...
- Installing vmware/vcf x.y.z ...
- Installed vmware/vcf x.y.z
...

Terraform has been successfully initialized!
```

--------------------------------

### Installing Wget on macOS

Source: https://github.com/vmware/terraform-provider-vcf/blob/main/docs/install.md

This command installs the `wget` utility on macOS using Homebrew, which is required for downloading the Terraform provider plugin from GitHub.

```console
brew install wget
```

--------------------------------

### Downloading VMware Cloud Foundation Provider Manually on Linux

Source: https://github.com/vmware/terraform-provider-vcf/blob/main/docs/install.md

This Bash command sequence is used for manual installation on Linux. It sets a `RELEASE` variable and then uses `wget` to quietly download the specified version of the `terraform-provider-vcf` zip file directly from the GitHub releases page.

```Console
RELEASE=x.y.z
wget -q https://github.com/vmware/terraform-provider-vcf/releases/download/v${RELEASE}/terraform-provider-vcf_${RELEASE}_linux_amd64.zip
```

--------------------------------

### Verifying Terraform VCF Provider Installation on macOS

Source: https://github.com/vmware/terraform-provider-vcf/blob/main/docs/install.md

These commands navigate to the installed plugin directory and list its contents, allowing verification that the Terraform VCF provider executable is correctly placed.

```console
cd ~/.terraform.d/plugins/local/vmware/vcf/${RELEASE}/darwin_amd64
ls
```

--------------------------------

### Verifying Terraform VCF Provider Installation on Windows

Source: https://github.com/vmware/terraform-provider-vcf/blob/main/docs/install.md

These PowerShell commands navigate to the installed plugin directory and list its contents, allowing verification that the Terraform VCF provider executable is correctly placed.

```powershell
cd $ENV:APPDATA\\terraform.d\\plugins\\local\\vmware\\vcf\\${RELEASE}\\windows_amd64
dir
```

--------------------------------

### Creating Terraform Local Plugin Directory Structure on Linux

Source: https://github.com/vmware/terraform-provider-vcf/blob/main/docs/install.md

This Bash command creates the necessary directory structure for manually installed Terraform plugins. The `-p` flag ensures that parent directories are created if they don't exist, following Terraform's expected hierarchy for local providers.

```Console
mkdir -p ~/.terraform.d/plugins/local/vmware/vcf/${RELEASE}/linux_amd64
```

--------------------------------

### Creating Terraform Plugin Directory on macOS

Source: https://github.com/vmware/terraform-provider-vcf/blob/main/docs/install.md

This command creates the necessary directory structure for the local Terraform provider plugin on macOS. Terraform uses this specific hierarchy to locate manually installed providers.

```console
mkdir -p ~/.terraform.d/plugins/local/vmware/vcf/${RELEASE}/darwin_amd64
```

--------------------------------

### Building the Terraform Provider Binary (Shell)

Source: https://github.com/vmware/terraform-provider-vcf/blob/main/docs/build.md

This snippet navigates into the cloned provider directory, fetches Go dependencies using 'go get', and then builds the provider binary named 'terraform-provider-vcf' using 'go build'. This compiles the source code into an executable for local development.

```sh
cd $GOPATH/src/github.com/vmware/terraform-provider-vcf
go get
go build -o terraform-provider-vcf
```

--------------------------------

### Verifying VMware Cloud Foundation Provider Presence in Local Directory

Source: https://github.com/vmware/terraform-provider-vcf/blob/main/docs/install.md

This Bash command sequence changes the current directory to the Terraform local plugins directory and then lists its contents. This allows verification that the `terraform-provider-vcf` binary has been successfully moved and is present in the correct location.

```Console
cd ~/.terraform.d/plugins/local/vmware/vcf/${RELEASE}/linux_amd64
ls
```

--------------------------------

### Checking Terraform Provider Version (Registry)

Source: https://github.com/vmware/terraform-provider-vcf/blob/main/docs/install.md

This console output shows the result of running `terraform version` when the VCF provider is sourced from the Terraform Registry. It displays the Terraform version and the installed provider version.

```console
$ terraform version
Terraform x.y.z
on linux_amd64
+ provider registry.terraform.io/vmware/vcf x.y.z
```

--------------------------------

### Downloading Terraform VCF Provider on Windows

Source: https://github.com/vmware/terraform-provider-vcf/blob/main/docs/install.md

This PowerShell command downloads the specified version of the Terraform VCF provider plugin for Windows (x64) from GitHub. The `$RELEASE` variable should be set to the desired version, and the file is saved locally.

```powershell
$RELEASE="x.y.z"
Invoke-WebRequest -Uri "https://github.com/vmware/terraform-provider-vcf/releases/download/v${RELEASE}/terraform-provider-vcf_${RELEASE}_windows_amd64.zip" -OutFile "terraform-provider-vcf_${RELEASE}_windows_amd64.zip"
```

--------------------------------

### Checking Terraform Provider Version (Manually Installed)

Source: https://github.com/vmware/terraform-provider-vcf/blob/main/docs/install.md

This console output shows the result of running `terraform version` when the VCF provider has been manually installed. It displays the Terraform version and confirms the local provider's version.

```console
$ terraform version
Terraform x.y.z
on linux_amd64
+ provider local/vmware/vcf x.y.z
```

--------------------------------

### Moving VMware Cloud Foundation Provider to Terraform Local Plugin Directory

Source: https://github.com/vmware/terraform-provider-vcf/blob/main/docs/install.md

This Bash command moves the extracted `terraform-provider-vcf` binary into the newly created Terraform local plugins directory. This step is crucial for Terraform to discover and use the manually installed provider.

```Console
mv terraform-provider-vcf_${RELEASE}/terraform-provider-vcf_v${RELEASE} ~/.terraform.d/plugins/local/vmware/vcf/${RELEASE}/linux_amd64
```

--------------------------------

### Downloading Terraform VCF Provider on macOS

Source: https://github.com/vmware/terraform-provider-vcf/blob/main/docs/install.md

This command downloads the specified version of the Terraform VCF provider plugin for macOS (Intel) from the GitHub releases page using `wget`. The `RELEASE` variable should be set to the desired version.

```console
RELEASE=x.y.z
wget -q https://github.com/vmware/terraform-provider-vcf/releases/download/v${RELEASE}/terraform-provider-vcf_${RELEASE}_darwin_amd64.zip
```

--------------------------------

### Extracting Terraform VCF Provider on macOS

Source: https://github.com/vmware/terraform-provider-vcf/blob/main/docs/install.md

This command extracts the downloaded Terraform VCF provider ZIP archive into a new directory named after the release version. The `unzip` utility is used for this purpose.

```console
unzip terraform-provider-vcf_${RELEASE}_darwin_amd64.zip -d terraform-provider-vcf_${RELEASE}
```

--------------------------------

### Extracting Terraform VCF Provider on Windows

Source: https://github.com/vmware/terraform-provider-vcf/blob/main/docs/install.md

These PowerShell commands extract the downloaded Terraform VCF provider ZIP archive and then change the current directory to the newly extracted folder, preparing for the next steps.

```powershell
Expand-Archive terraform-provider-vcf_${RELEASE}_windows_amd64.zip

cd terraform-provider-vcf_${RELEASE}_windows_amd64
```

--------------------------------

### Extracting Manually Downloaded VMware Cloud Foundation Provider

Source: https://github.com/vmware/terraform-provider-vcf/blob/main/docs/install.md

This Bash command extracts the contents of the previously downloaded `terraform-provider-vcf` zip file. The `-d` flag specifies a target directory, `terraform-provider-vcf_${RELEASE}`, to keep the extracted files organized.

```Console
unzip terraform-provider-vcf_${RELEASE}_linux_amd64.zip -d terraform-provider-vcf_${RELEASE}
```

--------------------------------

### Moving Terraform VCF Provider to Plugin Directory on Windows

Source: https://github.com/vmware/terraform-provider-vcf/blob/main/docs/install.md

These PowerShell commands first create the necessary directory structure for the local Terraform provider plugin on Windows and then move the extracted provider executable into this directory, making it discoverable by Terraform.

```powershell
New-Item $ENV:APPDATA\\terraform.d\\plugins\\local\\vmware\\vcf\\${RELEASE}\\ -Name "windows_amd64" -ItemType "directory"

Move-Item terraform-provider-vcf_v${RELEASE}.exe $ENV:APPDATA\\terraform.d\\plugins\\local\\vmware\\vcf\\${RELEASE}\\windows_amd64\\terraform-provider-vcf_v${RELEASE}.exe
```

--------------------------------

### Moving Terraform VCF Provider to Plugin Directory on macOS

Source: https://github.com/vmware/terraform-provider-vcf/blob/main/docs/install.md

This command moves the extracted Terraform VCF provider executable into the designated local Terraform plugins directory on macOS, making it discoverable by Terraform.

```console
mv terraform-provider-vcf_${RELEASE}/terraform-provider-vcf_v${RELEASE} ~/.terraform.d/plugins/local/vmware/vcf/${RELEASE}/darwin_amd64
```

--------------------------------

### Configuring Terraform for VMware Cloud Foundation Provider

Source: https://github.com/vmware/terraform-provider-vcf/blob/main/docs/install.md

This HCL snippet defines the basic Terraform configuration block, specifying the required `vcf` provider from `vmware/vcf` and setting the minimum required Terraform version to 1.4.0. This block enables Terraform to automatically download the provider from the Terraform Registry upon initialization.

```HCL
terraform {
  required_providers {
    vcf = {
      source = "vmware/vcf"
    }
  }
  required_version = ">= 1.4.0"
}
```

--------------------------------

### Configuring Terraform for Local VCF Provider

Source: https://github.com/vmware/terraform-provider-vcf/blob/main/docs/install.md

This HCL configuration block specifies the required provider for VMware Cloud Foundation (VCF) with a local source and a minimum version. It also sets the minimum required Terraform version for the configuration.

```hcl
terraform {
  required_providers {
    vcf = {
      source  = "local/vmware/vcf"
      version = ">= x.y.z"
    }
  }
  required_version = ">= 0.13"
}
```

--------------------------------

### Configuring Terraform with Version-Locked VMware Cloud Foundation Provider

Source: https://github.com/vmware/terraform-provider-vcf/blob/main/docs/install.md

This HCL snippet extends the basic Terraform configuration by adding a version constraint (`>= x.y.z`) for the `vcf` provider. This ensures that Terraform downloads a specific or newer version of the provider, providing better control over dependency management.

```HCL
terraform {
  required_providers {
    vcf = {
      source  = "vmware/vcf"
      version = ">= x.y.z"
    }
  }
  required_version = ">= 1.4.0"
}
```

--------------------------------

### Defining vcf_network_pool Resource Schema in HCL

Source: https://github.com/vmware/terraform-provider-vcf/blob/main/docs/resources/network_pool.md

This snippet defines the schema for the `vcf_network_pool` Terraform resource. It specifies the required `name` and `network` attributes, along with optional `network` and `timeouts` attributes. It also defines a read-only `id` attribute. The `network` block further defines nested attributes like `vlan_id`, `gateway`, `ip_pools`, `mask`, `mtu`, `subnet`, and `type`. The `ip_pools` block defines `start` and `end` IP addresses, and the `timeouts` block defines a `create` duration.

```HCL
resource "vcf_network_pool" "example" {
  name = "example-network-pool"
  network {
    vlan_id = 100
    type    = "VSAN"
    subnet  = "192.168.10.0/24"
    mask    = "255.255.255.0"
    gateway = "192.168.10.1"
    mtu     = 9000
    ip_pools {
      start = "192.168.10.10"
      end   = "192.168.10.20"
    }
  }
  timeouts {
    create = "30m"
  }
}
```

--------------------------------

### Defining Network IP Address Range Inclusion (Terraform HCL Schema)

Source: https://github.com/vmware/terraform-provider-vcf/blob/main/docs/resources/instance.md

This nested schema specifies a range of IPv4 addresses to be included within a network configuration. It requires both a starting and an ending IP address to define the contiguous range.

```Terraform HCL Schema
Required:
- end_ip_address (String) End IPv4 Address
- start_ip_address (String) Start IPv4 Address
```

--------------------------------

### Cloning the Terraform Provider Repository (Shell)

Source: https://github.com/vmware/terraform-provider-vcf/blob/main/docs/build.md

This snippet creates the necessary directory structure under $GOPATH/src/github.com/vmware and then clones the terraform-provider-vcf repository into it. This is the first step to set up the development environment for the provider.

```sh
mkdir -p $GOPATH/src/github.com/vmware
cd $GOPATH/src/github.com/vmware
git clone git@github.com:vmware/terraform-provider-vcf.git
```

--------------------------------

### Setting Up and Pushing New Feature Branch - Shell

Source: https://github.com/vmware/terraform-provider-vcf/blob/main/CONTRIBUTING.md

This snippet demonstrates the initial steps for contributing, including adding the upstream remote, creating and checking out a new feature branch from 'main', committing all changes, and pushing the new branch to the origin.

```shell
git remote add upstream https://github.com/vmware/terraform-provider-vcf.git
git checkout -b my-new-feature main
git commit -a
git push origin my-new-feature
```

--------------------------------

### Configuring Terraform Development Overrides (HCL)

Source: https://github.com/vmware/terraform-provider-vcf/blob/main/docs/build.md

This HCL snippet configures the ~/.terraformrc file to enable development overrides for the 'vmware/vcf' provider. It directs Terraform to load the provider binary from a specified local path, typically $GOPATH/bin, instead of downloading it from the Terraform Registry, facilitating local testing.

```hcl
provider_installation {
  dev_overrides {
    "vmware/vcf" = "/Users/rainpole/go/bin"
  }

  direct {}
}
```

--------------------------------

### Squashing Changes into Earlier Commit for Pull Request - Shell

Source: https://github.com/vmware/terraform-provider-vcf/blob/main/CONTRIBUTING.md

This snippet provides commands for squashing new changes into an earlier commit within a feature branch, useful for cleaning up commit history before a pull request. It stages all changes, creates a fixup commit for a specified '<commit>', interactively rebashes onto 'main' with autosquash, and then force-pushing the rebased branch to the origin with a lease.

```shell
git add .
git commit --fixup <commit>
git rebase -i --autosquash main
git push --force-with-lease origin my-new-feature
```

--------------------------------

### Upgrading Terraform Provider for VMware Cloud Foundation (Shell)

Source: https://github.com/vmware/terraform-provider-vcf/blob/main/README.md

This command upgrades the Terraform Provider for VMware Cloud Foundation to its latest version. It re-initializes the working directory and fetches the newest provider binaries from the Terraform Registry, ensuring that your configuration uses the most recent features and bug fixes.

```shell
terraform init -upgrade
```

--------------------------------

### Enabling Logging for Terraform VCF Provider (Shell)

Source: https://github.com/vmware/terraform-provider-vcf/blob/main/docs/index.md

This command enables detailed logging for the Terraform VCF provider by setting the `TF_LOG_PROVIDER_VCF` environment variable to `INFO`. This allows users to monitor provider activity and API task updates during Terraform runs, aiding in debugging and troubleshooting.

```Shell
export TF_LOG_PROVIDER_VCF=INFO
```

--------------------------------

### Configuring Terraform Provider for VMware Cloud Foundation (HCL)

Source: https://github.com/vmware/terraform-provider-vcf/blob/main/docs/index.md

This snippet demonstrates the basic configuration for the Terraform VCF provider. It declares the `vcf` provider as a required dependency and configures connection details to the SDDC Manager, including host, username, password, and an option to allow unverified TLS certificates, typically sourced from Terraform variables.

```HCL
terraform {
  required_providers {
    vcf = {
      source  = "vmware/vcf"
      version = "x.y.z"
    }
  }
}

provider "vcf" {
  sddc_manager_host     = var.sddc_manager_host
  sddc_manager_username = var.sddc_manager_username
  sddc_manager_password = var.sddc_manager_password
  allow_unverified_tls  = var.allow_unverified_tls
}
```

--------------------------------

### Syncing Feature Branch with Upstream Main - Shell

Source: https://github.com/vmware/terraform-provider-vcf/blob/main/CONTRIBUTING.md

This snippet shows how to update a local feature branch to stay in sync with the upstream 'main' branch. It involves checking out the feature branch, fetching all remotes, rebasing the feature branch onto 'upstream/main', and then force-pushing the rebased branch to the origin with a lease.

```shell
git checkout my-new-feature
git fetch -a
git pull --rebase upstream main
git push --force-with-lease origin my-new-feature
```

--------------------------------

### Defining vCenter Configuration Attributes (Terraform HCL Schema)

Source: https://github.com/vmware/terraform-provider-vcf/blob/main/docs/resources/instance.md

This schema defines the configuration parameters for a vCenter Server instance. It includes required attributes like the root password and hostname, along with optional settings for licensing, SSH/SSL thumbprints, and VM sizing.

```Terraform HCL Schema
Required:
- root_vcenter_password (String, Sensitive) vCenter root password. The password must be between 8 characters and 20 characters long. It must also contain at least one uppercase and lowercase letter, one number, and one character from '! \" # $ % & ' ( ) * + , - . / : ; < = > ? @ [ \ ] ^ _ ` { &Iota; } ~' and all characters must be ASCII. Space is not allowed in password.
- vcenter_hostname (String) vCenter Server hostname address. If just the short hostname is provided, then FQDN will be generated using the "domain" from dns configuration

Optional:
- license (String) vCenter License
- ssh_thumbprint (String) vCenter Server SSH thumbprint (RSA SHA256)
- ssl_thumbprint (String) vCenter Server SSL thumbprint (SHA256)
- storage_size (String) vCenter VM storage size. One among:lstorage, xlstorage
- vcenter_ip (String) vCenter Server IPv4 address
- vm_size (String) vCenter Server Appliance  size. One among: tiny, small, medium, large, xlarge
```

--------------------------------

### Defining NSX Configuration Attributes (Terraform HCL Schema)

Source: https://github.com/vmware/terraform-provider-vcf/blob/main/docs/resources/instance.md

This schema defines the configuration parameters for NSX-T Manager deployment. It includes required attributes for NSX Manager details, size, root password, transport VLAN, and VIP, along with optional settings for IP address pools, licensing, and additional user passwords.

```Terraform HCL Schema
Required:
- nsx_manager (Block List, Min: 1) Parameters for NSX manager (see [below for nested schema](#nestedblock--nsx--nsx_manager))
- nsx_manager_size (String) NSX-T Manager size. One among: medium, large
- root_nsx_manager_password (String, Sensitive) NSX Manager root password. Password should have 1) At least eight characters, 2) At least one lower-case letter, 3) At least one upper-case letter 4) At least one digit 5) At least one special character, 6) At least five different characters , 7) No dictionary words, 6) No palindromes
- transport_vlan_id (Number) Transport VLAN ID
- vip (String) Virtual IP address which would act as proxy/alias for NSX Managers
- vip_fqdn (String) FQDN for VIP so that common SSL certificates can be installed across all managers

Optional:
- ip_address_pool (Block List, Max: 1) NSX IP address pool specification (see [below for nested schema](#nestedblock--nsx--ip_address_pool))
- license (String, Sensitive) NSX Manager license
- nsx_admin_password (String, Sensitive) NSX admin password. The password must be at least 12 characters long. Must contain at-least 1 uppercase, 1 lowercase, 1 special character and 1 digit. In addition, a character cannot be repeated 3 or more times consecutively.
- nsx_audit_password (String, Sensitive) NSX audit password. The password must be at least 12 characters long. Must contain at-least 1 uppercase, 1 lowercase, 1 special character and 1 digit. In addition, a character cannot be repeated 3 or more times consecutively.
- overlay_transport_zone (Block List, Max: 1) NSX OverLay Transport zone (see [below for nested schema](#nestedblock--nsx--overlay_transport_zone))
```

--------------------------------

### Defining Network Configuration Attributes (Terraform HCL Schema)

Source: https://github.com/vmware/terraform-provider-vcf/blob/main/docs/resources/instance.md

This schema defines the configuration parameters for a network within a VCF deployment. It includes essential network settings like MTU, network type, and VLAN ID, along with optional parameters for teaming policies, IP address management, and port group keys.

```Terraform HCL Schema
Required:
- mtu (String) MTU size
- network_type (String) Network Type. One among: VSAN, VMOTION, MANAGEMENT, VM_MANAGEMENT or any custom network type
- vlan_id (String) VLAN Id

Optional:
- active_up_links (List of String) Active Uplinks for teaming policy, specify uplink1 for failover_explicit VSAN Teaming Policy
- exclude_ip_address_ranges (List of String) IP Address ranges to be excluded
- exclude_ip_addresses (List of String) IP Addresses to be excluded
- gateway (String)
- include_ip_address (List of String)
- include_ip_address_ranges (Block List) (see [below for nested schema](#nestedblock--network--include_ip_address_ranges))
- port_group_key (String) Portgroup key name. When adding a cluster with a new DVS, this value must be provided. When adding a cluster to an existing DVS, this value must not be provided.
- standby_uplinks (List of String) Standby Uplinks for teaming policy, specify uplink2 for failover_explicit VSAN Teaming Policy
- subnet (String)
- subnet_mask (String)
- teaming_policy (String) Teaming Policy for VSAN and VMOTION network types, Default is loadbalance_loadbased. One among: loadbalance_ip, loadbalance_srcmac, loadbalance_srcid, failover_explicit, loadbalance_loadbased
```

--------------------------------

### Declaring vcf_edge_cluster Resource in Terraform

Source: https://github.com/vmware/terraform-provider-vcf/blob/main/docs/resources/edge_cluster.md

This HCL (HashiCorp Configuration Language) snippet demonstrates how to declare a `vcf_edge_cluster` resource in a Terraform configuration. It includes all the required parameters such as administrator, audit, and root passwords for the NSX manager, the desired form factor, high availability mode, MTU, cluster name, and profile type. It also includes a placeholder for the `edge_node` block, whose specific attributes are not detailed in the provided documentation.

```HCL
resource "vcf_edge_cluster" "example" {
  admin_password    = "your_admin_password"
  audit_password    = "your_audit_password"
  form_factor       = "LARGE"
  high_availability = "ACTIVE_ACTIVE"
  mtu               = 9000
  name              = "my-edge-cluster"
  profile_type      = "DEFAULT"
  root_password     = "your_root_password"

  edge_node {
    # The specific attributes for 'edge_node' are not detailed in the provided schema.
    # Typically, these would include properties like:
    # host_id      = "host-id-123"
    # datastore_id = "datastore-id-456"
    # network_ids  = ["network-id-789"]
    # ip_address   = "192.168.1.10"
    # gateway      = "192.168.1.1"
    # netmask      = "255.255.255.0"
    # dns_servers  = ["8.8.8.8"]
    # ntp_servers  = ["pool.ntp.org"]
  }
}
```

--------------------------------

### Defining NSX Manager Configuration Attributes (Terraform HCL Schema)

Source: https://github.com/vmware/terraform-provider-vcf/blob/main/docs/resources/instance.md

This nested schema defines the configuration parameters for an individual NSX Manager within a cluster. It allows specifying the hostname and IPv4 address for each manager.

```Terraform HCL Schema
Optional:
- hostname (String) NSX Manager hostname. If just the short hostname is provided, then FQDN will be generated using the "domain" from dns configuration
- ip (String) NSX Manager IPv4 Address
```

--------------------------------

### Amending Most Recent Commit for Pull Request - Shell

Source: https://github.com/vmware/terraform-provider-vcf/blob/main/CONTRIBUTING.md

This snippet illustrates how to amend the most recent commit in a feature branch, typically used when a pull request needs minor changes or fixes. It stages all changes, amends the last commit, and then force-pushes the updated branch to the origin with a lease.

```shell
git add .
git commit --amend
git push --force-with-lease origin my-new-feature
```

=== COMPLETE CONTENT === This response contains all available snippets from this library. No additional content exists. Do not make further requests.