mount module doesn't work correctly with mount option "bind"

[jamesgoodhouse]

Issue Type:

Bug Report

Ansible Version:

ansible 1.5.4

Environment:

Ansible is running from OS/X Mavericks 10.9.2
I am managing an Ubuntu 12.04 instance

Summary:

When using the mount module and specifying an option of "bind", the filesystem is mounted over and over. This has been tracked down to what appears to be Python's os.path.ismount(path) returning false for any mounts with the bind option applied.

Steps To Reproduce:

Create a mount using the mount module with the following options:

• fstype: none
• opts: rw,bind
• state: mounted

Expected Results:

I expect to see the mount point show up in /etc/fstab, the mount point to show when the command "mount" is ran in the terminal, and for the Ansible task to not show as "changed" for each run when no change has occurred.

Actual Results:

The mount point shows up properly in /etc/fstab, but the mount point is mounted each time the Ansible task is ran, causing it to be mounted over and over on the system as well as for the Ansible task to show the status of "changed".

[kilburn]

I have hit the same bug. It seems that the root of this problem is that Python's os.path.ismount(path) function does not detect bind-mounts. I'm looking for a solution...

[jamesgoodhouse]

That was the route I was thinking needed to be taken, but yeah, Linux only. I would think falling back to os.path.ismount() would be preferable.

[bcoca]

It might be better to use the same functions that fact gathering already does which ARE cross OS

[kilburn]

I totally agree that unifying this code with the facts module code would be good (DRY).

That being said, the get_mount_facts() function is not cross OS. Most other UNIX-like systems (at least *BSDs, OS X, and Solaris) do not have the /etc/mtab file used by that function.

If I were to try to improve that, where should I put the helper function retuning the list of mounts? To clarify, code from the get_mount_facts() function cannot be directly called from another module because that function fills a property within its containing class instance instead of returning the list of mounts. Thus, I would have to introduce a helper function that returned the list of mounts. I'm asking where should that go...

[bcoca]

@marc, there is more than one get_mount_facts function, they are in 'per
OS' classes.​ For example, check under FreeBSD and you'll see the specific
one (line 1008 of the same file).

[kilburn]

@bcoca touché, I didn't see that. Still... that code is not correct, or at least it is not providing the same information than the linux code. Namely, the FreeBSD's get_mount_facts() code is not retrieving the currently mounted filesystems. It retrieves the entries in /etc/fstab, yet those are just mount point definitions which may or may not be mounted. Furthermore, there may be mounted devices which are not configured in /etc/fstab (and thus not detected by that function).

Anyway, can you give me a hint on how would I be able to use that code from the mount module?

[bcoca]

I have not used the new 'integrated' facts yes, but I would guess you create an object from the generic class, which will substitute itself with the specific one and then you can just call the .get_mount_facts method on that. Check other modules, they are probably using this already.

[Jmainguy]

The ansible facts gathered by facts.py does not show bind mounts. Any feedback on how to improve #8524 would be great.

[mmoya]

My suggestion is to parse /proc/mounts instead of the ouput of mount. I've been bitten by stale mount output in some AWS instances with 12.04. I those cases I just soft-linked /etc/mtab to /proc/mounts and haven't see any problem.

[mpdehaan]

Hi!

Thanks very much for your interest in Ansible. It sincerely means a lot to us.

On September 26, 2014, due to enormous levels of contribution to the project Ansible decided to reorganize module repos, making it easier
for developers to work on the project and for us to more easily manage new contributions and tickets.

We split modules from the main project off into two repos, http://github.com/ansible/ansible-modules-core and http://github.com/ansible/ansible-modules-extras

If you would still like this ticket attended to, and believe this problem or idea is still present in the latest version of Ansible (1.7.2) or the development branch, we will need your help in having it reopened in one of the two new repos, and instructions are provided below.

We apologize that we are not able to make this transition happen seamlessly, though this is a one-time change and your help is greatly appreciated --
this will greatly improve velocity going forward.

Both sets of modules will ship with Ansible, though they'll receive slightly different ticket handling.

To locate where a module lives between 'core' and 'extras'

• Find the module at http://docs.ansible.com/list_of_all_modules.html
• Open the documentation page for that module
• If the bottom of the docs say "This is an extras module", submit your ticket to https://github.com/ansible/ansible-modules-extras
• Otherwise, submit your pull request to update the existing module to https://github.com/ansible/ansible-modules-core
• action_plugins (modules with server side components) still live in the main repo. If your ticket affects both, open the ticket
  on the module repo just the same.

Additionally, should you need more help with this, you can ask questions on:

• the ansible-project mailing list: https://groups.google.com/forum/#!forum/ansible-project

Thank you very much!