as in pull #67922 has modify vsphere cloud provider to report
node hostname, this patch is to add the test for it.
also fix an issue at InstanceID(), it suppose to return
cloudprovider.InstanceNotFound when vm not found, after the fix,
test TestInstance() can pass
Rather than just looking for zone tags at the VM's Host level, traverse up the hierarchy.
This allows zone tags to be attached at host level, along with cluster, datacenter, root folder
and any inventory folders in between.
Issue #64021
- Add tests for GetZones()
- Fix bug where a host tag other than region or zone caused an error
- Fix bug where GetZones() errored if zone tag was set, but region was not
Follow up to PR #66795 / towards #64021
Zones implementation for vSphere cloud provider needs dependencies
which are not included in current vmware/govmomi vendor. So this
update added "vapi" package to support zones.
Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.
Add error check and ignore unused variable (SA4006)
**What this PR does / why we need it**:
Fix some bugs in cloud provider vsphere, issue can be found here #66303
```pkg/cloudprovider/providers/vsphere/nodemanager.go:176:5: defers in this range loop won't run unless the channel gets closed (SA9001)
pkg/cloudprovider/providers/vsphere/vclib/diskmanagers/vmdm.go:129:8: this value of err is never used (SA4006)
pkg/cloudprovider/providers/vsphere/vsphere.go:596:34: argument ctx is overwritten before first use (SA4009)
pkg/cloudprovider/providers/vsphere/vsphere_test.go:360:2: this value of instanceID is never used (SA4006)
pkg/cloudprovider/providers/vsphere/vsphere_util.go:301:3: defers in this infinite loop will never run (SA5003)
```
**Special notes for your reviewer**:
I fixed ```SA4006``` report in that issue, but there are still other code needed to discuss and fix.
**Release note**:
```release-note
NONE
```
Automatic merge from submit-queue (batch tested with PRs 66122, 66007). If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.
Return vmUUID when renewing nodeinfo in VCP
**What this PR does / why we need it**:
This PR fixes an issue that VM UUID is removed when renewing node information in vSphere cloud provider
**Which issue(s) this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close the issue(s) when PR gets merged)*:
Fixes #
**Special notes for your reviewer**:
**Release note**:
```release-note
NONE
```
/sig vmware
These are all flagged by Go 1.11's
more accurate printf checking in go vet,
which runs as part of go test.
Lubomir I. Ivanov <neolit123@gmail.com>
applied ammend for:
pkg/cloudprovider/provivers/vsphere/nodemanager.go
Setting the client UserAgent makes it easier to identify vCenter sessions
used by the vSphere Cloud Provider. This is useful to remove sessions that
have leaked, such as when a VCP process goes away without calling Logout().
And to test that VCP properly re-authenticates when a session is removed.
Example use:
govc session.ls | grep kubernetes-cloudprovider | awk '{print $1}' | xargs -n1 govc session.rm
Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.
Setup TLS with CA Cert for vsphere cloud provider
- Extend config to take a path to a CA Certificate
- Use the CA Cert when establishing a connection with the SOAP client
Testing
We provide certs and keys for tests as fixtures, `vclib/fixtures`.
Those were created (and can be regenerated) using `vclib/fixtures/createCerts.sh`.
At the moment it's possible to configure a CA path and at the same time allow insecure
communication between vsphere cloud provider and vcenter. This may
change in the future; we might opt for overwriting the insecure
communication if a CA is configured / log and transparently pass the
arguments to the vcenter command / other. To be discussed.
At the moment the CA is a global level configuration. In other
words, all vcenter servers need to use certificates signed by the same
CA. There might be use cases for different CA per vcenter server; to be
discussed.
**What this PR does / why we need it**:
This PR adds the option of configuring a trusted CA for the communication between the vsphere cloud provider and the vcenter control plane.
**Which issue(s) this PR fixes**:
Fixes#64222
**Special notes for your reviewer**:
**Release note**:
```release-note
- Can configure the vsphere cloud provider with a trusted Root-CA
```
Automatic merge from submit-queue (batch tested with PRs 65507, 65508, 65486). If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.
Fix typo in vsphere cloud provider comment
**What this PR does / why we need it**:
Fix typo in code of vsphere cloud provider
As far as I know, it's not purchased by Google right..?
**Which issue(s) this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close the issue(s) when PR gets merged)*:
Fixes #
**Special notes for your reviewer**:
**Release note**:
```release-note
NONE
```
- Extend config to take a path to a CA Certificate
- Use the CA Cert when establishing a connection with the SOAP client
Testing
We provide certs and keys for tests as fixtures, `vclib/fixtures`.
Those were created (and can be regenerated) using `vclib/fixtures/createCerts.sh`.
At the moment it's possible to configure a CA path and at the same time allow insecure
communication between vsphere cloud provider and vcenter. This may
change in the future; we might opt for overwriting the insecure
communication if a CA is configured / log and transparently pass the
arguments to the vcenter command / other. To be discussed.
At the moment the CA is a global level configuration. In other
words, all vcenter servers need to use certificates signed by the same
CA. There might be use cases for different CA per vcenter server; to be
discussed.
