On Fri, Feb 25, 2011 at 2:06 PM, Stefan Schulte <
stefan.schu...@taunusstein.net> wrote:
>
> I'm not really satisfied with the mount provider and I tried to explain
> that in »Refactoring mounttype«.
>
Ah, thanks for pointing that out. I saw that e-mail when you sent it but I
didn't give it the attention I should have. I'm now up to speed.
>
> I dont know if using flush to do the actual mount/umount/remount is such
> a great idea. Some thoughts:
> * if i specify ensure => absent: Is every OS able to umount a resource
> if we erase the entry in fstab beforehand ? (but wait, I guess we can
> overwrite flush in a way that it does umount before)
>
Yes, my intention was that we overwrite flush in a way that does umount
before. In fact, the order of operations I had in mind was:
1. umount anything that needs unmounting (this includes both resources that
have { ensure => unmounted } and resources that are changing and have {
remounts => false })
2. write /etc/fstab
3. mount anything that needs mounting (this includes using "-o remount" for
resources that have { remounts => true })
> * is flush called when there was no change (when fstab is completly in
> sync, but the actual mount is not)?
>
Flush is only called when at least one parameter was out of sync (including
"ensure"). So we would need to make sure that ensure.insync? returns false
in this situation. I believe that will be straightforward to do.
> * does the user gets informed about changes? I'm asking this because my
> normal puppet usage is using noop until I'm sure I can apply the
> changes and then run no-noop. Is flush called when running noop? If
> noop shows everything in sync and running no-noop afterwards would
> suddenly umount it can really break stuff.
>
>
Flush does not get called in noop mode, but the events and log messages
related to the parameters get handled as usual. This means you would still
get messages like "notice: /Stage[main]//Mount[/Volumes/NIKON_D40X]/device:
device changed '/dev/disk1s1' to '/dev/disk1s2'" (and the corresponding
entries in the report). And in particular, since flush only gets called
when at least one parameter was out of sync, you can be assured that if noop
shows everything in sync, running no-noop will have no effect.
Does that address your concerns?
> > Let me know if you have any other immediate plans for the mount provider
> so
> > we can coordinate.
>
> I'm thinking about splitting the mount type in two independent pieces.
> fstab present/absent and actual mount mounted/umounted. I dont know when
> I have time to work on it and I dont even know if thats a good idea. I
> guess it would fit the API much better if puppet can sync them
> indepently but I'm not sure if this will raise more problems than it
> solves.
>
Ok, thanks. I will keep this in mind as I'm working.
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to puppet-dev@googlegroups.com.
To unsubscribe from this group, send email to
puppet-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
