Bug 883877

Seems like an error translation issue in StorageHelperBase (PosixStorageHelper extends it but does not override the relevant methods).

regarldess of the version this is aimed at, it seems like an easy fix. Devel-acking.

issue is that vdsm is propagating a general exception.
Need to fix in vdsm side.
getRecord (in mount.py) is throwing an OSError
        raise OSError(errno.ENOENT,
                "Mount of `%s` at `%s` does not exist" %
                (self.fs_spec, self.fs_file))
But _translateConnectionError (in hsm.py) is expecting a MountError
        if isinstance(e, mount.MountError):

*** Bug 893383 has been marked as a duplicate of this bug. ***

Fixed according to Ayal's comment.
http://gerrit.ovirt.org/#/c/10966
Change-Id: I0f36b3ea18690d7cf53439e5a0342b1495f4f181

Now the error code is 477, and Error message in the engine:
The connection with details server.example.com:/export/VMs failed because of error code 477 and error message is: problem while trying to mount target

Duplicate of Bug 883879?

(In reply to comment #2)
> issue is that vdsm is propagating a general exception.
> Need to fix in vdsm side.
> getRecord (in mount.py) is throwing an OSError
>         raise OSError(errno.ENOENT,
>                 "Mount of `%s` at `%s` does not exist" %
>                 (self.fs_spec, self.fs_file))
> But _translateConnectionError (in hsm.py) is expecting a MountError
>         if isinstance(e, mount.MountError):

This trace is an artefact of any fail in the mount raising OSError.

In order to understand the real issue, patch:
http://gerrit.ovirt.org/12042
(among others)
should be applied.

Example:

Thread-2351::DEBUG::2013-03-17 03:02:48,704::misc::85::Storage.Misc.excCmd::(<lambda>) '/usr/bin/sudo -n /bin/mount -t glusterfs filer03.qa.lab.tlv.redhat.com:/DORON1 /rhev/data-center/mnt/filer03.qa.lab.tlv.redhat.com:_DORON1' (cwd None)
Thread-2351::ERROR::2013-03-17 03:02:48,798::hsm::2299::Storage.HSM::(connectStorageServer) Could not connect to storageServer
Traceback (most recent call last):
  File "/usr/share/vdsm/storage/hsm.py", line 2296, in connectStorageServer
    conObj.connect()
  File "/usr/share/vdsm/storage/storageServer.py", line 219, in connect
    fileSD.validateDirAccess(self.getMountObj().getRecord().fs_file)
  File "/usr/share/vdsm/storage/mount.py", line 271, in getRecord
    (self.fs_spec, self.fs_file))
OSError: [Errno 2] Mount of `filer03.qa.lab.tlv.redhat.com:/DORON1` at `/rhev/data-center/mnt/filer03.qa.lab.tlv.redhat.com:_DORON1` does not exist


When the real issue is(with a patch in the spirit of 12042):
Thread-33::ERROR::2013-03-17 03:23:45,802::storageServer::212::StorageServer.MountConnection::(connect) Mount failed: (1, 'Mount failed. Please check the log file for more details.\n;/sbin/mount.glusterfs: line 130: /usr/sbin/glusterfs: Permission denied\n')
Traceback (most recent call last):
  File "/usr/share/vdsm/storage/storageServer.py", line 210, in connect
    self._mount.mount(self.options, self._vfsType)
  File "/usr/share/vdsm/storage/mount.py", line 222, in mount
    return self._runcmd(cmd, timeout)
  File "/usr/share/vdsm/storage/mount.py", line 238, in _runcmd
    raise MountError(rc, ";".join((out, err)))
MountError: (1, 'Mount failed. Please check the log file for more details.\n;/sbin/mount.glusterfs: line 130: /usr/sbin/glusterfs: Permission denied\n')

MountError was caught and swallowed after failed mount in storageServer.py .
The OSError should not have been sent or reached to begin with.

Verified, tested on RHEVM 3.3 - IS14 environment:

Host OS: RHEL 6.5

RHEVM:  rhevm-3.3.0-0.21.master.el6ev.noarch
PythonSDK:  rhevm-sdk-python-3.3.0.13-1.el6ev.noarch
VDSM:  vdsm-4.12.0-127.gitedb88bf.el6ev.x86_64
LIBVIRT:  libvirt-0.10.2-23.el6.x86_64
QEMU & KVM:  qemu-kvm-rhev-0.12.1.2-2.401.el6.x86_64
SANLOCK:  sanlock-2.8-1.el6.x86_64

*** Bug 949292 has been marked as a duplicate of this bug. ***

This bug is currently attached to errata RHBA-2013:15291. If this change is not to be documented in the text for this errata please either remove it from the errata, set the requires_doc_text flag to 
minus (-), or leave a "Doc Text" value of "--no tech note required" if you do not have permission to alter the flag.

Otherwise to aid in the development of relevant and accurate release documentation, please fill out the "Doc Text" field above with these four (4) pieces of information:

* Cause: What actions or circumstances cause this bug to present.
* Consequence: What happens when the bug presents.
* Fix: What was done to fix the bug.
* Result: What now happens when the actions or circumstances above occur. (NB: this is not the same as 'the bug doesn't present anymore')

Once filled out, please set the "Doc Type" field to the appropriate value for the type of change made and submit your edits to the bug.

For further details on the Cause, Consequence, Fix, Result format please refer to:

https://bugzilla.redhat.com/page.cgi?id=fields.html#cf_release_notes 

Thanks in advance.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2014-0040.html

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days