On Fri, Feb 25, 2011 at 02:40:25PM -0800, Paul Berry wrote:
>
> 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 })Sounds good to me. > > > > * 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. Ok so you want to introduce a dummy property for the situation that fstab is in sync but the mount is not? Something like »ensure is 'out of sync mounted' should be 'mounted'« or something similar? And then fix that in the flush method. I guess thats not the most informative message in the world but propably ok. > > * 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? Looks good to me. I think with this approach we can fix #6309 and #6411 (at least sync the actual device property; options is much harder) and get around selfrefresh to also fix #6027. #4184 is propably best solved in the :pre_gen hook of the parsed file provider. #6409 seems to be a simple validate. The one I currently dont know how to address (besides splitting the current type in two fstab-only mount-only types) is #5991 -Stefan
pgpKQjvi41TGV.pgp
Description: PGP signature
