rancher: creating vsphere cluster errors on all nodes with Error in driver during machine creation: yaml: unmarshal errors
What kind of request is this (question/bug/enhancement/feature request): Bug
Steps to reproduce (least amount of steps as possible):
- Create fresh rancher HA installation across 3 nodes, deploy 2.3.3
- Add vsphere credential
- Add vsphere node templates, selecting options, add cloud-config
- Create cluster using node templates using rancheros from boot2docker
Result:
- All nodes fail to create with unmarshal error 2019/11/28 17:22:33 [INFO] Creating jail for c-xp2gr 2019/11/28 17:22:33 [INFO] Generating and uploading node config 2019/11/28 17:22:34 [INFO] [node-controller-docker-machine] The default lines below are for a sh/bash shell, you can specify the shell you’re using, with the --shell flag. 2019/11/28 17:22:34 [INFO] [node-controller-docker-machine] 2019/11/28 17:22:34 [INFO] Generating and uploading node config evovsphere-wrkr-a-1 2019/11/28 17:22:34 [ERROR] NodeController c-xp2gr/m-wnjxh [node-controller] failed with : Error creating machine: Error in driver during machine creation: yaml: unmarshal errors: 2019/11/28 17:24:20 [INFO] Removing node evovsphere-wrkr-b-1
Other details that may be helpful:
Environment information
- Rancher version (
rancher/rancher
/rancher/server
image tag or shown bottom left in the UI): 2.3.3 - Installation option (single install/HA): HA
Cluster information
-
Cluster type (Hosted/Infrastructure Provider/Custom/Imported): hosted vsphere
-
Machine type (cloud/VM/metal) and specifications (CPU/memory): vsphere
-
Kubernetes version (use
kubectl version
): 1.15.4-rancher1-2 -
Docker version (use
docker version
): 19.03
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 24 (11 by maintainers)
Commits related to this issue
- Improve Vsphere UX around cloudinit/cloudconfig There was confusion and misuse around cloudinit and cloudconfig. This change switches things up so cloudinit is only used for the legacy creation type ... — committed to codyrancher/ui by codyrancher 5 years ago
- Improve Vsphere UX around cloudinit/cloudconfig There was confusion and misuse around cloudinit and cloudconfig. This change switches things up so cloudinit is only used for the legacy creation type ... — committed to codyrancher/ui by codyrancher 5 years ago
- Improve Vsphere UX around cloudinit/cloudconfig There was confusion and misuse around cloudinit and cloudconfig. This change switches things up so cloudinit is only used for the legacy creation type ... — committed to codyrancher/ui by codyrancher 5 years ago
- Improve Vsphere UX around cloudinit/cloudconfig There was confusion and misuse around cloudinit and cloudconfig. This change switches things up so cloudinit is only used for the legacy creation type ... — committed to codyrancher/ui by codyrancher 5 years ago
- Improve Vsphere UX around cloudinit/cloudconfig There was confusion and misuse around cloudinit and cloudconfig. This change switches things up so cloudinit is only used for the legacy creation type ... — committed to codyrancher/ui by codyrancher 5 years ago
- Improve Vsphere UX around cloudinit/cloudconfig There was confusion and misuse around cloudinit and cloudconfig. This change switches things up so cloudinit is only used for the legacy creation type ... — committed to westlywright/ui by codyrancher 5 years ago
@bmdepesa The changes are backported and available in
latest-2.3
@AntonSmolkov it will continue to be supported, the method of deploying in vsphere is being deprecated in favor of official OVAs and template cloning which is more in line with the vSphere UI.
As a temporary workaround you can pass your cloud-init through node-templates’s guestinfo parameter - guestinfo.cloud-init.config.data