The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

Bug #14199

Mount resource don't recognize already mounted resources if there is a symlink in mountpoint path

Added by Rafał Kupka almost 2 years ago. Updated over 1 year ago.

Status:Code InsufficientStart date:04/26/2012
Priority:NormalDue date:
Assignee:-% Done:

50%

Category:mount
Target version:3.x
Affected Puppet version:2.7.14 Branch:https://github.com/puppetlabs/puppet/pull/1289
Keywords:mount symlink

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com

This ticket may be automatically exported to the PUP project on JIRA using the button below:


Description

Mount command (and /proc/mounts file) only shows mountpoint path with symlinks resolved. Puppet don’t recognize this resources as already mounted.

More information:

#grep /sl /etc/fstab
/dev/sda9 /srv/sl xfs rw 0 0

# ls -l /srv/sl
lrwxrwxrwx 1 root root 5 Apr 26 14:07 /srv/sl -> video

# mount | grep video
/dev/sda9 on /srv/video type xfs (...)

# puppet apply --noop -e 'mount { "/srv/sl": ensure => mounted; }' 
notice: /Stage[main]//Mount[/srv/sl]/ensure: current_value unmounted, should be mounted (noop)
notice: /Stage[main]//Mount[/srv/sl]: Would have triggered 'refresh' from 1 events

Puppet version with attached patch applied works fine. Github patch

puppet_mount.patch Magnifier (2 KB) Rafał Kupka, 04/26/2012 09:03 am

puppet-mount.patch Magnifier - Patch type/mount.rb to support symlinked mountpoints (387 Bytes) Christoph Rauch, 09/05/2012 06:22 am

History

#1 Updated by Daniel Pittman almost 2 years ago

  • Status changed from Unreviewed to Needs Decision

#2 Updated by Christoph Rauch over 1 year ago

I created a patch for this situation by introducing a munger in the name parameter of the mount type. This is only done if there exists a path with that name in the filesystem, when there is no path existing the old behaviour (just returning the name) is retained.

Please review this patch.

#3 Updated by Vladimir Kozhukalov over 1 year ago

CHRISTOPH RAUCH, I sent your patch via github, mentioned your authorship.

#4 Updated by Jeff McCune over 1 year ago

  • Status changed from Needs Decision to Code Insufficient
  • Branch set to https://github.com/puppetlabs/puppet/pull/1289

Please see the comments in the pull request at: https://github.com/puppetlabs/puppet/pull/1289 for next actions.

@kozhukalov

Thanks for the pull request!

Type vs Providers

I notice this check is in the munge block for the type. Will this cause issues when puppet agent is run on a separate node as the puppet master? That is to say, the munge block will only be executed when the compiler produces a catalog in the master, not when the agent applies the catalog, right?

Code – missing examples

Before we merge this into Puppet examples that exercise this change in behavior need to be included in the patch. If you’re not comfortable adding RSpec examples, I’m happy to help out. I’m jmccune in #puppet-dev on freenode. Please include examples that will automatically let us know if this problem resurfaces in the future, otherwise we may have a regression as we continue to make changes over time.

Next Steps

  1. Please consider changing the provider instead of the type.
  2. Please add examples that exercise this behavior. Existing spec tests should provide a good starting point.

I’m going to go ahead and close this pull request for the time being. Please re-open this pull request once new information is available, or if you have any questions or concerns. Closing the pull request doesn’t mean we don’t consider this change valuable, just that there are things that need to be addressed before it can be merged. If you have any questions or concerns, please don’t hesitate to ping us in #puppet-dev on irc.freenode.net.

#5 Updated by Jeff McCune over 1 year ago

  • Target version changed from 2.7.15 to 3.x
  • Affected Puppet version set to 2.7.14

Also available in: Atom PDF