This message was deleted.
# vsphere
a
This message was deleted.
a
What values.yaml are you talking about exactly?
I have used network protocol profiles / vApp properties successfully (I used https://code.spamasaurus.com/djpbessems/Go.NPP-Prepper to configure both vCenter and VM), but did not use any values.yaml.
I have since moved away from NPP though, now using in-cluster IPAM instead.
w
Thanks for the reply - this is specific to Rancher cluster templates, which we deploy as Helm charts. We plan to use an answers file/values.yaml to specify customizable defaults for the admins to use when deploying new clusters.
The problem, to the best of my understanding, is because we specify vappProperties like this:
Copy code
vappProperty:
  - 'guestinfo.interface.0.ip.0.address=${autoIp:vDS-My-Server-Network}'
  - 'guestinfo.interface.0.route.0.gateway=${gateway:vDS-My-Server-Network}'
The special characters are being mishandled by Helm when deploying the chart, resulting in the error above. There are at least a couple of workarounds. Either: 1. Specify the properties as text formatted as a JSON array; or 2. Update the vSphere-specific template to iterate the array and quote each item.
Even though I’m past the deployment issue, though, I still haven’t managed to make this work. Since I haven’t found any working examples of using a cluster template with vSphere and vApp/NPP, I suspect that my guess of the format of the vappProperty values is still wrong.
a
These vApp properties are of type 'Expression' instead of the default 'string'; without that distinction, your values (which are correct in format) will not be evaluated and replaced.
I didn't use helm to deploy my cluster templates, so not sure if you can escape them?
\${expression}
w
I expected that I could, but this seems like one of the places that Helm’s deep magick results in mysterious behaviors. Thanks for confirming the format of the properties; it occurs to me that I might need different keys. If I figure that bit out I’ll reply here.
In the end it was pretty simple. First, we had to fix
charts/templates/nodeconfig-vsphere.yaml
in the RKE2 cluster template example repository by replacing:
Copy code
vappProperty: {{ $nodepool.vappProperty }}
with:
Copy code
{{- if $nodepool.vappProperty }}
vappProperty:
{{- range $nodepool.vappProperty }}
  - {{ . | quote }}
{{- end }}
{{- end }}
in two places. This took care of the error I posted at the top of this thread.
With that fixed, one can add the properties exactly as I described earlier. A cloud-init script that runs when the machine is provisioned, as outlined in Easy Static IP Configuration for Rancher Nodes, can query the values and use them to configure the network. (We did not use the script provided in this blog post, but leveraged the bits used to pull in guestinfo.ovfEnv and extract configuration to feed to
nmcli
.)
a
Cool find; in all my searches for NPP related content I never found something so comprehensive, but I stopped using them before that post was written it seems.