http://projects.puppetlabs.com/issues/6309#note-11
I'm just going to paste Paul's excellent note here inline, as we really want feedback on this. TL;DR The mount provider has used a mish-mash of checking fstab and actual mount state to determine state. A possible solution we're looking at is splitting into two types, one that manages /etc/fstab (or /etc/filesystem on other OSes), and one that manages actual mount state. --------- The fundamental issue here, as I understand it, is that we want the mount provider to be able to manage two separate pieces of system state: * What device is currently mounted at each potential mount point (and with what options). * What device is currently listed in fstab for each potential mount point (and with what options). * But we only let the user specify one piece of state in the manifest. When making changes to system state, this is not necessarily a problem. Most of the time, people want the data in fstab to match what is currently mounted. And we’ve been able to hack around the cases where they don’t by defining special meanings for the “ensure” property (mounted/unmounted/defined/present/absent as opposed to the usual present/absent). The place where it becomes a problem is when querying system state: if what is listed in fstab differs from what is presently mounted, which should the mount provider report as the “current” state of the system? Currently the mount provider reports the contents of fstab as the “current” state. The reason this matters is beacuse Puppet’s resource harness will only instruct the provider to make a change to system state when the property is “out of sync”, which means that the “desired” state of a property (as specified in the manifest) fails to match the “current” state of that property (as queried from the running system). So if the data in fstab matches the “desired” state, the resource harness won’t instruct the provider to make any changes to the system, and so we won’t bother trying to remount anything. After some discussion with Markus, the possible solutions I can imagine are: 1. Break the mount type into two types, one that represents data in fstab and one that represents what’s actually mounted at any given time (I believe Nigel has talked about this idea before, but I can’t locate any documentation of that). Unfortunately, this would not be compatibile with existing users' manifests because it would require them to split each of their “mount” resources into two resources. 2. Like (1), but address the compatibility problem by creating a mechanism that automatically converts each of the user’s “mount” resources into a pair of resources, one for the fstab and one for the mountedness of the device. (This might be achievable with a defined type but I’m not certain). 3. Add properties to the mount type so that its properties can accurately capture the full state of the machine (both fstab and mounts). Unfortunately, this would also break existing users' manifests because it would require them to add properties to each of their “mount” resources. 4. Like (3), but address the compatibility problem by creating a mechanism that automatically populates the additional properties with the appropriate values when the user doesn’t specify them. 5. Create a new, ersatz value for the “ensure” property called “incorrectly_mounted”, which the user is not allowed to specify in the manifest, but which is reported by the provider as the “current” state when fstab doesn’t properly match what is currently mounted. This will ensure that the resource harness instructs the provider to take actions whenever fstab doesn’t match the current mounted state, so that the provider can try to fix the problem. Solutions 1 and 3 are definitely not feasible for 2.6, since they would introduce incompatibilities. Solutions 2 and 4 are potentially ok for 2.6, but the magnitude of those changes is large enough that it seems like it would be better to postpone until Statler. Solution 5 is a terrible kludge, and is likely to be quite brittle considering that we would have to build it on top of two other kludges: (1) the fact that the “ensure” property is overloaded to handle mounted/unmounted/defined/present/absent, and (2) the fact that there is already an ersatz value “ghost” to represent situations where the desired device is mounted but has no entry in fstab. -- Nigel Kersten Product, Puppet Labs @nigelkersten -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
