FEATURE: also allow per-host connection details in resource config

[bish0polis]

Terraform-provider-esxi provides a host config to manage ESXi hosts in a very host-centric way which is also very standard:

https://github.com/josenk/terraform-provider-esxi/blob/master/examples/07%20Networking/main.tf#L8

provider "esxi" {
  esxi_hostname = var.esxi_hostname
  esxi_hostport = var.esxi_hostport
  esxi_hostssl  = var.esxi_hostssl
  esxi_username = var.esxi_username
  esxi_password = var.esxi_password
}

That is, define each host with a different provider and with separate connection details between hosts. I've found that in cases where I'm defining a series of ESXi hosts and their details - in my case, prepping for licensing and joining a cluster - repeating the same info in several different host definitions and their config details gives us a config load that is more challenging to consolidate. It'd be nice to use the same config info between several hosts without modularizing the setup.

Terraform-provider-redfish, for instance, provides a per-host config that allows for some per-host connection details to over-ride that information configured globally into the provider:

https://github.com/dell/terraform-provider-redfish/blob/68363fab3c52898d6ac22ffdf427b3136c466c7e/examples/users/users.tf#L9

resource "redfish_user_account" "rr" {
  for_each = var.rack1

  redfish_server {
    user         = each.value.user
    password     = each.value.password
    endpoint     = each.value.endpoint
    ssl_insecure = each.value.ssl_insecure
  }

  username = "mike"
  password = "test1234"
  role_id  = "Operator"
  enabled  = true
}

In this example, the per-host config in the resource itself supplements what may be in the provider config, and allows for a single config instance to represent many otherwise identical hosts.

Having initially thought it to be strange and unwieldy, I've since worked with this particular oddity, and the way this allows for simplification of the config is a huge benefit.

Please, consider adding this if the opportunity presents.

[josenk]

I didn't try to reproduce what your asking, but I don't think redfish is doing anything special... It looks like it's just doing a for_each of the rack1 variable. That technique should work with any resource, but I'm not sure about using that technique for the provider variables???

You may want to look at Workspaces and/or Variable Definitions (.tfvars) to see if they provide what you are looking for.

https://developer.hashicorp.com/terraform/cli/workspaces Variable Definitions (.tfvars) https://terraformguru.com/terraform-certification-using-azure-cloud/23-Input-Variables-Assign-with-tfvars-var-file/

[bish0polis]

I think this is different from my read of either tfvars or workspaces. No need to reproduce the environment, as it's not complex. Let me compare.

Scenario: 10 HPe or Dell boxes arrive at the same location for the same environment. Instead of manual config, we opt for as much TF as we can: redfish for the BMC, ESXi for the initial setup and networking, and vsphere for most of those once they're alive. (Let's forget the MAAS/dRebar part as it provokes sobbing) The iLO or iDrac will be configured with

• one provider statement, including local creds
• one set of configs to encompass all 10 hosts via a for_each to iterate through endpoints

The ESXi config will be

• 10 provider statements
• 10 separate (but ideally modularized) configs for 10 hosts, each one using a different provider alias.

And while modularization reduces half the work, it's still 10 different provider statements, or one per machine in the same environment and in the same TF-plan invocation. Scale that out a bit and it gets worrisome.

The different setup in the redfish provider is weird, and they do spend a lot of space explaining how it's different and why; and I still thought it was hokey until I actually used it. So if you're thinking it offers minimal value or looks weird or can be replicated by trickery that seems similar, it's only my inability to properly explain.

If you - or a contributor with time! My priority once I can book time to get into go is a set-hostname trivial practice change and then maybe a vmk and port-binding - if someone does have time and space to look at this because luck gives them a RedFish-capable BMC, and if someone can look at the coding workflow change, I'm sure it'll show its value quickly.

Can we leave this open on the wish-list until then?

[josenk]

This plugin creates VMs on an ESXi host, it doesn't really configure the ESXi host... Is that what you're looking for?