[01:38] <timClicks> hpidcock: hey I might get your advice on some go codegen stuff if you have a minute?
[01:38] <hpidcock> sure, want to HO?
[01:38] <timClicks> cool
[01:39] <timClicks> the file I'm looking at is https://github.com/juju/juju/blob/a5ab92ec9b7f5da3678d9ac603fe52d45af24412/provider/vsphere/internal/vsphereclient/ovf_ubuntu.go
[01:39] <timClicks> I'm concerned that we're hard coding xenial in there
[01:39] <timClicks> it's built from https://github.com/juju/juju/blob/a5ab92ec9b7f5da3678d9ac603fe52d45af24412/provider/vsphere/internal/vsphereclient/ubuntu.ovf
[04:16] <timClicks> hpidcock: the VM we're trying to create has the same MAC address as the tmp VM that creates it "
[04:16] <timClicks>     The static MAC address (00:50:56:04:71:0c) of juju-4e9d86-0 conflicts with MAC assigned to juju-4e9d86-0.tmp
[04:16] <timClicks> "
[04:17] <hpidcock> Is that just a side affect of not deleting the tmp vm?
[04:18] <timClicks> trying to figure that out
[04:19] <hpidcock> Ideally the provider should: "Download the OVA", "Upload the OVA to the datastore", "Create a VM from the OVA", "Update tuneables like mem/cpu", "Extend vmdk", "Start"
[04:21] <hpidcock> possibly the reason it mutates the ovf before creating the vm, is that vsphere might have some bin-packing algorithm maybe to find a suitable esxi host
[04:26] <timClicks> I think the VM cloning operation also clones the MAC address as it's been provided in "hardcoded" form by Juju
[14:04] <manadart> hml: That WiP: https://github.com/juju/juju/pull/10442. Still a few packages to get green; diff will be > 100 files I think.
[14:06] <hml> manadart: ta