Issue #6027 has been updated by Daniel Pittman. Status changed from Accepted to Closed
Hey. Our long term plan is to factor out the mount provider into two parts, one for fstab and one for mount. This issue is pretty much around the fusion of the two as we have them, so I am going to close it for now. We should have it fixed as part of that big split-up. ---------------------------------------- Bug #6027: 'mount -o remount' isn't always the appropriate way to effect a change https://projects.puppetlabs.com/issues/6027 Author: eric sorenson Status: Closed Priority: Normal Assignee: Category: mount Target version: Affected Puppet version: Keywords: Branch: this started out as a side note to #4914 but Stefan asked me to raise it as a separate issue. The problem is that some types of mount point changes do not take effect when the 'remount' code path is taken in the mount provider. For example, changing the nfs server or (apparently, though I haven't expereinced this myself) physical device for a local mount for a mount triggers 'mount -o remount /mount/point' through puppet, but this does not actually change the mounted filesystem. I think the upshot is 'mount -o remount' is only appropriate for changes to 'options' attribute, and it would be ideal for puppet to be aware of what attributes are under change and if they're ones which require a full unmount/mount, to do that. As a brutal workaround, I've just set :remounts to false everywhere (lib/type/mount.rb , newparam(:remounts) ..) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
