Skip to content
This repository has been archived by the owner on Nov 9, 2020. It is now read-only.

Detach after mount failure, and a small fix for logs #1005

Merged
merged 4 commits into from
Mar 8, 2017

Conversation

msterin
Copy link
Contributor

@msterin msterin commented Mar 8, 2017

Make sure we detach after fresh volume mount failure (before returning failure to Docker)

  • on create, volume is created, then attached , then mounted for formatting
  • If the mount fails for whatever reason, Mount() used to drop the refcount and immediately return failure to upstairs - without detaching.

Fix some warning to print correctly

  • We need to use warning_f_ for formatted strings

Testing

Manual:

  • validated the log, e.g. Failed to load config file /etc/docker-volume-vsphere.conf. (it used to be Failed to load config file %s /etc/docker-volume-vsphere.conf
  • during mount failure testing, observed that after failed mount I see Detaching vol2 - it is not used anymore message and VMDK is detached from the VM

Mark Sterin added 2 commits March 7, 2017 17:37
Also make us a little bit more patient on slow disk attach
(may happen due to slow VM reconfig on overloaded system)
refcnt, _ := d.decrRefCount(r.Name)
if refcnt == 0 {
log.Infof("Detaching %s - it is not used anymore", r.Name)
d.ops.Detach(r.Name, nil) // try to detach before failing the request for volume
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should you be calling "d.UnmountVolume(r.Name)" like in Unmount?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Logically we do not want to unmount since we know the mount has failed. We just want to clean up the attach.
Technically UnmountVolume does a set of useless calls (i.e. tries to locate the name and unmount volume) which we know will fail and guarantee confusing messages about failing to unmount, and then it will do the only useful step (d.ops.Detach) which we can do directly.

I guess that was a long winded version of "no. we need to call Detach" :-)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

😀 yes, makes sense.

Copy link
Contributor

@pdhamdhere pdhamdhere left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Contributor

@govint govint left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good.

@msterin msterin self-assigned this Mar 8, 2017
@msterin msterin merged commit bb17f08 into master Mar 8, 2017
@msterin msterin deleted the detach_and_logs.msterin branch March 8, 2017 18:44
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants