Re: [Puppet-dev] mount provider discussion

[Paul Berry]

On Fri, Feb 25, 2011 at 2:06 PM, Stefan Schulte <stefan....@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.

[Stefan Schulte]

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

[Markus Roberts]

P & S --

The one I currently dont know how to address (besides splitting the
current type in two fstab-only mount-only types) is #5991

I have to say that this one appeals to me a lot for some reason, though I'm not as deep in the weeds as the two of you and may be missing subtleties.  I think it may just be a background bias that splitting a three-way-merge/reconciliation into two two-way-merges/reconciliations is generally the right thing to do.

-- M
-----------------------------------------------------------
When in trouble or in doubt, run in circles,
scream and shout. -- 1920's parody of the 
maritime general prudential rule
------------------------------------------------------------

[Stefan Schulte]

On Fri, Feb 25, 2011 at 02:40:25PM -0800, Paul Berry wrote:

> On Fri, Feb 25, 2011 at 2:06 PM, Stefan Schulte <
> stefan....@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'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.
>

Since there is now an RFC on puppet-users I wanted to say that I
actually found some time to work on splitting the types. If you're
interested you can see the changes here:
https://github.com/stschulte/puppet/commits/refactor%2Fnext%2Fmount_split

If splitting is the way to go and there is an official ticket number
I'll rename my brach.

I'm not done yet and I only did a few short tests on my linux box. It
would really help if someone could provide me with detailed sample mount
outputs from HP-UX, Solaris and Darwin and AIX. E.g looking at

https://github.com/puppetlabs/puppet/blob/7e71840e29cb09c772668a51ada3cab1e319e50f/test/data/providers/mount/parsed/solaris.mount

I cannot see that I can extract fstype from it? Has Solaris somesort of
/etc/mtab? Is this one better than parsing mount?

And what is the device on Darwin when mount shows something like this:
map -hosts on /net (autofs, nosuid, automounted, nobrowse)

Is fstype is always the first option on darwin?

-Stefan