We used to provide the cloud-init user-data and meta-data to the VM as
key/value in the VM's extraConfig as guestinfo keys. This replaces bunch
of code that used to create an ISO, upload it to VSphere and attach it
to the VM.
We recently started to observe issues when uploading the ISO to our
testing VSphere instance in CI. This commit aims to circumvent this
issue by using a different and simpler way to provide the cloud-init
data to the VM.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Re-enable the vmware tests on RHEL 10 and use vcenter 8 instead of 6. This fixes the issues caused by outdated CPUs in old cluster by migrating to a new one with new hosts as well.
both are defined in CI, but the GOVC_ prefix doesn't match anything
else. Additionally this value is slightly different for vCenter8 and may
lead to failures if not unified.
Specify the resource pool when importing the VMDK to the VCenter.
This should prevent the following error:
govc: default resource pool resolves to multiple instances, please specify
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Add a common function to check for all environment variables needed to
test VSphere image. Call the function from all S3 implementations of
`checkEnv()` if testing the VSphere image type.
Move the installation of the VSphere client out of the
`api/common/aws.sh` `installClient()` function into a dedicated
`installClientVSphere()` function in `api/common/vsphere.sh`.
Rename the `installClient()` in `api/common/aws.sh` to
`installAWSClient()`. Introduce `installClient()` in both,
`api/aws.sh` and `api/aws.s3.sh`, which calls `installAWSClient()`.
Call `installClientVSphere()` conditionally when testing VMDK image type
in `api/aws.s3.sh` and `api/generic.s3.sh`.
