Issue #3688 has been updated by Ian Dall.
The crucial question seems to be: Is there any realistic use case where the current behaviour is required? I can't think of one. As I pointed out, a remount will fail anyway. If the "remounts" property is false, an explicit unmount (and mount) will be tried, but that will almost always fail too, because something will be keeping the filesystem "busy". So I see no harm in checking both the device and the name. It is less clear whether it would also be desirable to check the fstype. ---------------------------------------- Bug #3688: Can not overmount a mountpoint. http://projects.puppetlabs.com/issues/3688 Author: Ian Dall Status: Needs more information Priority: Normal Assigned to: James Turnbull Category: mount Target version: Affected version: 0.25.4 Keywords: Branch: I have diskless linux clients where /var/spool is mounted with type tmpfs. I want to overmount (on certain clients) with and nfs mount. The issue is that in type/mount.rb does: provider.mount unless provider.mounted? when ensure=>mounted. Looking in provider/mount.rb, for the definition of provider.mounted, it just checks for the / on #{name} / in the list of mounts. This succeeds no matter what was mounted (in my case a tmpfs), even if it was completely unrelated to the desired mount. On a refresh, the remount fails as well for slightly different reasons: basically a remount will only change some mount options, not completely change the mounted device and filesystem type. I'm not sure what is correct here. While it might seem strange to want to do this, the tmpfs mount comes earlier in the boot process and is not under puppet's control. I general, it seems wrong for puppet's behaviour to depend on how the underlying filesystem has been constructed. I think it would be reasonable for provider.mounted to check both the device and the name to determine if a mount is already mounted. There are issues such as how to compare "devices" where one is an nfs "device" with a short hostname and one a long hostname, or where one uses a symlink and another doesn't. This is no different to problems which arise where the mount point is a symlink. "Don't do that!" seems to be the answer. -- 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.
