You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 7, 2022. It is now read-only.
Before every attach, vSphere cloud provider checks if the SCSI controller is present on the VM. If not present, it will try to create one and attach the disk to that SCSI controller on VM. If already present, it will use the SCSI controller.
For the very first time when SCSI controller is not present on the VM, we try to create one and retrieve the SCSI controller for the disk to created on that SCSI controller. But in release 1.7, after successful creation of SCSI controller, we are not assigning back the SCSI controller to the existing "scsicontroller" variable. Because of this the very first time, attach of the disk will fail.
This problem is not observed on master, as we have taken care of this in vSphere cloud provider refactoring - kubernetes#49164
This is a very minor fix and needs to made in 1.7 and 1.6 branch.
The text was updated successfully, but these errors were encountered:
BaluDontu
changed the title
Attempt to Attach Volume fails for very first time on 1.7 branch
Attempt to Attach Volume fails for very first time on 1.7 and 1.6 release branches
Aug 23, 2017
Before every attach, vSphere cloud provider checks if the SCSI controller is present on the VM. If not present, it will try to create one and attach the disk to that SCSI controller on VM. If already present, it will use the SCSI controller.
For the very first time when SCSI controller is not present on the VM, we try to create one and retrieve the SCSI controller for the disk to created on that SCSI controller. But in release 1.7, after successful creation of SCSI controller, we are not assigning back the SCSI controller to the existing "scsicontroller" variable. Because of this the very first time, attach of the disk will fail.
This problem is not observed on master, as we have taken care of this in vSphere cloud provider refactoring - kubernetes#49164
This is a very minor fix and needs to made in 1.7 and 1.6 branch.
The text was updated successfully, but these errors were encountered: