On Sun, Feb 20, 2011 at 3:41 AM, Stefan Schulte <[email protected]> wrote: > Hi, > > i recently worked a little bit with the mounttype to implement > prefetching and the type always felt kind of messy: > > - we try to ensure two things with one type and property: State in fstab > and state in mtab (Problem #6309 is based on that) (ensure can reflect > mounted, umounted, absent, present, correct fstab but uncorrectly mounted) > - in transaction.rb it says: We sync ensure first and that should fix > all other properties as well. Thats not correct for a mounttype: If we > sync from absent to mounted the behaviour is correct because we will > create fstab with correct options and mount with correct options -> > everything is in sync. But if we sync from present to mounted we start > to hack to also sync the other properties. But the user does not see > any of this (#5991). By the way: The same is true for a service. If we > specify ensure => running, enabled => true and both properties are out > of sync, transaction only syncs ensure and withing the ensure block we > sync enabled (which is not reported to the user). > - We have dependencies between the properties. If we change options we > have to remount. Thats why the mount type is set to selfrefresh. But > there are also problems with that (#6027) > > I thought about how to improve the current mount type to match the > current API and I just came up with two ideas (dont know if they are > doable) > > Idea 1: > > - transaction could continue to sync after we sync ensure. So basically > treat ensure like any other property. Because this will break existing > types that rely on this behaviour we could then introduce a new > property method that will flag the property as »If you sync me, any > following properties are in sync«. > - not use self refresh but extend the flush method. If the fstab is > flushed to disk we can compare the should state of options and device > and the current state from mount output and > either do a »mount -o remount« or a »umount; mount« > > Now the following can happen > is: ensure => present, options => rw > should: ensure => mounted, options => ro > > Transaction will sync ensure first that will mount our resource (with > wrong options), then options is synced and fstab is flushed to disk. > Because flush detects that our resource is currently mountet rw and not > ro, we will remount. > > 2. > > Reduce the mount type to only handle /etc/fstab (present,absent) and create > a second type to only handle the actual mount (mounted/umounted). To not > break the current behaviour the first type may be able to delegate/ > automatically create an instance of the second type and establish > dependecies between them. Now transaction will sync fstab and the actual > mount independently. > > I would be happy to know your opinion about the mount type and the > ideas.
Stefan, thanks for bringing this up, I think we're all starting to converge on similar opinions in all these threads about mount bugs. My preference is for the latter solution, 2), as it seems much simpler for users to understand, and is much more flexible. I'd suggest that for backwards compatibility reasons we should just produce two new types, one an fstab entry type, the other a mountpoint type. -- You received this message because you are subscribed to the Google Groups "Puppet Developers" 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-dev?hl=en.
