-
Notifications
You must be signed in to change notification settings - Fork 39.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use local PX endpoint for mount, unmount, detach and attach calls #48898
Use local PX endpoint for mount, unmount, detach and attach calls #48898
Conversation
Hi @harsh-px. Thanks for your PR. I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
76a8c74
to
a0d6aa1
Compare
/assign @gnufied |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some minor nits - mostly lgtm
@@ -266,7 +266,7 @@ func (b *portworxVolumeMounter) SetUp(fsGroup *int64) error { | |||
// SetUpAt attaches the disk and bind mounts to the volume path. | |||
func (b *portworxVolumeMounter) SetUpAt(dir string, fsGroup *int64) error { | |||
notMnt, err := b.mounter.IsLikelyNotMountPoint(dir) | |||
glog.V(4).Infof("Portworx Volume set up: %s %v %v", dir, !notMnt, err) | |||
glog.Infof("Portworx Volume set up. Dir: %s %v %v", dir, !notMnt, err) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we really want to log these messages always in the log files? Looks to me that, older logging priority was more accurate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have found tracking down events for volume setup and teardown very important in debugging field issues and hence I've changed the logging level. SetupAt
and TearDownAt
get invoked only when pods get scheduled on a new node (new pod or existing pod getting re-scheduled). So these logs entries won't be very chatty.
pkg/volume/portworx/portworx_util.go
Outdated
return volumeID, requestGB, nil, err | ||
} | ||
|
||
// DeleteVolume deletes a Portworx volume | ||
func (util *PortworxVolumeUtil) DeleteVolume(d *portworxVolumeDeleter) error { | ||
driver, err := util.getPortworxDriver(d.plugin.host) | ||
driver, err := util.getPortworxDriver(d.plugin.host, false) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Everywhere we add a naked true
or false
argument - we should also add a comment of the form true /*localOnly*/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done in incremental diff
pkg/volume/portworx/portworx_util.go
Outdated
@@ -181,13 +186,24 @@ func createDriverClient(hostname string) (*osdclient.Client, error) { | |||
} | |||
} | |||
|
|||
func (util *PortworxVolumeUtil) getPortworxDriver(volumeHost volume.VolumeHost) (volumeapi.VolumeDriver, error) { | |||
func (util *PortworxVolumeUtil) getPortworxDriver(volumeHost volume.VolumeHost, localOnly bool) (volumeapi.VolumeDriver, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you document - what that localOnly
flag does? Why certain calls supply this as true
while others as false
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a function doc in the incremental
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I read the comment - and I still don't understand why CreateDisk
and DeleteDisk
pass this flag as false
while others as true
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Feel free to link to some external docs if the context is large enough to not fit in a code comment. We frequently do that in AWS and other volume plugins (or we should be doing that).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please see if the update comment gives more context. I have given a high-level context on why create and delete calls can use localOnly as false while other's cannot.
Currently, we don't have external docs describing our internal algorithms (most of them are proprietary.)
pkg/volume/portworx/portworx_util.go
Outdated
if err != nil { | ||
return nil, err | ||
} else { | ||
glog.Infof("Using portworx local service at: %v as api endpoint", volumeHost.GetHostName()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO - this log message should only appear if verbosity is set to a lower level, not always.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed to glog.V(4)
in the incremental
@k8s-bot ok to test |
Re-run of the failing test succeeded. |
8e4f1f8
to
90919e3
Compare
/lgtm |
@gnufied Thanks for reviewing this. I am guessing you are the only who adds the approved label? |
/approve |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: gnufied, harsh-px No associated issue. Update pull-request body to add a reference to an issue, or get approval with The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these OWNERS Files:
You can indicate your approval by writing |
@harsh-px can you open a github issue and link this PR there? |
@gnufied Created issue and linked here. |
Automatic merge from submit-queue (batch tested with PRs 48997, 48595, 48898, 48711, 48972) |
@gnufied I need to cherry-pick this into the next 1.7 and 1.6 release. However, the cherry-pick PR would need the milestone label set for these releases in this PR. What is the process for getting these milestone labels? |
@harsh-px you open the PRs against the branches. Since change here is mostly a bug fix, it would be cherry picked by release manager of those branches. |
/release-note Fixes an issue where a pod using a Portworx volume gets stuck in ContainerCreating phase. |
…98-upstream-release-1.7 Automated cherry pick of #48898 upstream release 1.7
…98-upstream-release-1.6 Automatic merge from submit-queue Automated cherry pick of #48898 upstream release 1.6 **What this PR does / why we need it**: This PR fixes an issue with Setup and TearDown of Portworx volumes which has side-effects such a Pod using a Portworx volume not being able to start on the minion. **Which issue this PR fixes**: This PR addresses an issue that fails to mount, attach, unmount or detach a volume when Kubernetes sends these requests to Portworx when it's API server on that particular minion is down. Portworx mount, unmount, attach and detach requests need to be received on the minion where the pod is running. So these calls need to talk to the Portworx API server running locally on that node (and NOT to the Portworx k8s service since it may route the request to any node in the cluster). This PR explicitly makes such requests local only. Cherrypick of #48898
What this PR does / why we need it:
This PR fixes an issue with Setup and TearDown of Portworx volumes which has side-effects such a Pod using a Portworx volume not being able to start on the minion.
Which issue this PR fixes: fixes #49034
This PR addresses an issue that fails to mount, attach, unmount or detach a volume when Kubernetes sends these requests to Portworx when it's API server on that particular minion is down.
Portworx mount, unmount, attach and detach requests need to be received on the minion where the pod is running. So these calls need to talk to the Portworx API server running locally on that node (and NOT to the Portworx k8s service since it may route the request to any node in the cluster). This PR explicitly makes such requests local only.
Release note: