Update govmomi, vsphere provider internals #7855

Merged
merged 1 commit into from Sep 15, 2017

Conversation

Projects
None yet
3 participants
Member

axw commented Sep 14, 2017

Description of change

Update to the latest vmware/govmomi, which
has a few signature changes, e.g. updating
to use the standard "context" package. We
also update some existing internals and
introduce new vsphereclient Client methods
for use in an upcoming PR.

QA steps

  1. juju bootstrap vsphere
  2. juju add-machine
  3. juju add-machine --series=xenial
    (ensure machines are created successfully)
  4. juju destroy-controller -y vsphere --destroy-all-models

Documentation changes

None.

Bug reference

None.

just a small correction

@@ -585,7 +587,8 @@ func (u *statusUpdater) loop(abort <-chan struct{}) error {
}
type leaseUpdaterContext struct {
- lease *object.HttpNfcLease
+ //lease *object.HttpNfcLease
@axw

axw Sep 14, 2017

Member

thanks, fixed

Update govmomi, vsphere provider internals
Update to the latest vmware/govmomi, which
has a few signature changes, e.g. updating
to use the standard "context" package. We
also update some existing internals and
introduce new vsphereclient Client methods
for use in an upcoming PR.
Member

axw commented Sep 14, 2017

$$merge$$

Contributor

jujubot commented Sep 14, 2017

Status: merge request accepted. Url: http://ci.jujucharms.com/job/github-merge-juju

@jujubot jujubot merged commit c4fe14e into juju:develop Sep 15, 2017

1 check passed

continuous-integration/jenkins/pr-merge This commit looks good
Details

jujubot added a commit that referenced this pull request Sep 15, 2017

Merge pull request #7856 from axw/vsphere-cache-vmdk
provider/vsphere: cache VMDKs in datastore

## Description of change

Cache VMDKs in a controller-specific location
in the datastore, and use that when creating
VMs. This serves two purposes:

 - to avoid downloading and uploading for each
   new virtual machine
 - to avoid having to upload to the hosts, as
   we were previously doing (uploading to the
   NFC lease location)

We now also avoid downloading the OVA to disk,
instead piping the VMDK contents to the datastore
upload.

The VMDK we upload to the datastore is not stored
in the virtual disk format, so to create a functioning
VM we must:
 1. create a temporary VM with the VMDK attached
 2. clone that VM to create a copy of the VMDK in
   the virtual disk format

We continue to use OVF/ImportVApp for the purpose
of creating the initial VM, which keeps things the
same between vCenter and ESXi. Instead of pulling
the OVF out of the OVA file, we now store an OVF
definition in the source tree and compile it in. This
means we don't have to read the OVA file at all if
the VMDK is already cached.

This PR is based on top of #7855, so you can ignore the first commit.

## QA steps

1. juju bootstrap vsphere
2. juju add-machine --constraints root-disk=20G
3. juju add-machine --series=trusty
(ensure all machines come up OK, and check in debug-log that the machine added in step 2 did not incur an upload; ssh to machine from step 2 to check its root disk size is 20GiB)
4. check datastore, it should have VMDKs cached in juju-vmdks/<controller-uuid>/{xenial,trusty}.
5. delete the cache from datastore
6. juju add-machine
(ensure machine comes up OK)
7 juju destroy-controller -y vsphere --destroy-all-models
(ensure datastore cache is deleted automatically)

## Documentation changes

None.

## Bug reference

https://bugs.launchpad.net/juju/+bug/1711019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment