VSphere provider not properly setting unit hostname

Bug #1669072 reported by Charles Butler
22
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Canonical Juju
Fix Released
High
Andrew Wilkins

Bug Description

When deploying to a vsphere provider we have here on premise it appears that every ubuntu guest VM provisioned by juju gets the hostname "ubuntuguest". This is problematic in deployments that require FQDN to be resolveable.

Even if the units have a DNS entry, the dns server is likely to round robin distribute them, possibly connecting units to the wrong endpoint. For example, kubernetes uses the FQDN hostname to contact for operations like kubectl exec and kubectl logs (both of which are mandatory in conformance testing).

This seems reproduceable enough that we've identified failure modes for our conformance testing, and its indicative that something between juju and vsphere aren't setting things up properly. It would be great if cloud-init could assign the VM the name of the VM itself.

Version:
2.1.1-xenial-amd64

This is with vsphere 6.0:

VMware vCenter Server 6.0.0, 3634794
VMware ESXi 6.0.0, 3620759

Larry Michel (lmic)
tags: added: oil
Larry Michel (lmic)
description: updated
Larry Michel (lmic)
tags: added: oil-2.0 vsphere
Larry Michel (lmic)
tags: added: cdo-qa-blocker
Changed in juju:
status: New → Triaged
importance: Undecided → Critical
milestone: none → 2.2-beta1
Tim Penhey (thumper)
tags: added: sprint
Revision history for this message
Charles Butler (lazypower) wrote :

I was made aware this morning of a NSS plugin for juju that could potentially resolve this behavior.

https://bugs.launchpad.net/juju/+bug/1590961

tags: added: kubernetes
removed: sprint
Revision history for this message
Adam Stokes (adam-stokes) wrote :

We are getting ready to add user visible support to vsphere and this issue would be a blocker for us.

tags: added: conjure
Changed in juju:
importance: Critical → High
assignee: nobody → Horacio Durán (hduran-8)
Changed in juju:
milestone: 2.2-alpha1 → 2.2-beta1
Changed in juju:
status: Triaged → In Progress
Revision history for this message
Horacio Durán (hduran-8) wrote :

The current decission is to pass a hostname to cloudinit so it can set a different, distinctive hostname to each machine.
The hostname should be composed of part of the model uuid and the machine id.
So far I have been looking how to make all the relevant bits reach cloudinit.

Changed in juju:
assignee: Horacio Durán (hduran-8) → Andrew Wilkins (axwalk)
Revision history for this message
Andrew Wilkins (axwalk) wrote :

I've just dumped out the VM spec that we pass in, and it has a "hostname" property that has a default value of "ubuntuguest". I'm testing a change now that sets it to the instance ID that we assign (i.e. something like juju-f33df4c3-0).

That seems to work, but now there are hostname resolution errors (sudo: unable to resolve host juju-be2f09-0). It's not clear to me how the DNS knows about "ubuntuguest" -- maybe that's been set up manually? I guess we'll need to add the hostname to /etc/hosts.

Revision history for this message
Andrew Wilkins (axwalk) wrote :

That's no good, because other charms want to be able to resolve the hostname too.

Revision history for this message
Andrew Wilkins (axwalk) wrote :

This is as good as we'll get for now. Need to look into DNS/DHCP story further.

https://github.com/juju/juju/pull/7148

Changed in juju:
status: In Progress → Fix Committed
Revision history for this message
Andrew Wilkins (axwalk) wrote :

With this change in place, and with HTTP/S proxies configured in the kubernetes-worker charm, I've now got Kubernetes up and running on vCenter 6.0.0. I ran the microbot action to smoke test, and the deployed web app is responding happily.

Changed in juju:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.