RFC: Refactoring the mount provider.
Nigel Kersten
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
Christian Kauhaus
> 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.
+1
Regards
Christian
--
Dipl.-Inf. Christian Kauhaus <>< � k...@gocept.com � systems administration
gocept gmbh & co. kg � forsterstra�e 29 � 06112 halle (saale) � germany
http://gocept.com � tel +49 345 1229889 11 � fax +49 345 1229889 1
Zope and Plone consulting and development
Patrick
On Mar 17, 2011, at 10:40 AM, Nigel Kersten wrote:
> 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.
+1
Thomas Bellman
> 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.
[Details elided]
Two separate types is the obviously correct way. Just like we
have two separate types for specifying whether a service should
be started at boot and for whether it should be running right
now. And just like we have nine separate types for specifying
file type, owner, group, mode, content and SElinux parameters.
...
Hey wait, we don't! We only have one service type and one file
type, with multiple properties. Maybe there is some good reason
for having it like that. Perhaps like not requiring users to
repeat the same things (service name; file path; mount-point and
device) for things that very, very often go together.
So, no, I think splitting the mount type into two types would be
a bad choice.
Splitting the 'ensure' parameter of the mount type into two, on
the other hand, I think is a very good idea.
The nice way to transition would be to have two entirely new
parameters, let's provisionally call them 'mount_state' and
'fstab_state', and in 2.7 have the 'ensure' parameter translated
into those two new parameters with a warning about that syntax
being deprecated, and then in 2.8 remove the 'ensure' parameter
entirely. (I actually dislike the names I propose above; they
are just examples for the sake of discussing the principle.)
/Bellman
Stefan Schulte
I disagree. Lets say you define something like this
mount { '/mnt/foo':
device => '/dev/foo',
options => 'ro',
mount_state => mounted
fstab_state => present
}
and lets also say that options is 'ro' in fstab but someone mounted the
device 'rw'. What should puppet report now? Is the »options« property
insync now? If not, what is its current value? ro or rw? What if its the
other way around? Wrong entry in fstab but correctly mounted?
Yes you have to specify device etc two times. Yes I want '/dev/foo' in
fstab and yes surprisingly I also want to actually mount '/dev/foo'. But
that makes sense because you also have two is-states (current device in
fstab and current device that is mounted on /mnt/foo).
So splitting the mounttype can lead to better reports when puppet sync
mountpoint and entry in fstab seperatly. Because I'm lazy I'll propably
write a define (maybe I will call it mount) that will create two
resources for the two new types.
> /Bellman
>
-Stefan
Nigel Kersten
<stefan....@taunusstein.net> wrote:
> So splitting the mounttype can lead to better reports when puppet sync
> mountpoint and entry in fstab seperatly. Because I'm lazy I'll propably
> write a define (maybe I will call it mount) that will create two
> resources for the two new types.
If we did decide to make this change, we would probably try to get
such a define/wrapped type that preserved existing semantics into core
as well, so people could choose to use it.
Felix Frank
> mount { '/mnt/foo':
> device => '/dev/foo',
> options => 'ro',
> mount_state => mounted
> fstab_state => present
> }
>
> and lets also say that options is 'ro' in fstab but someone mounted the
> device 'rw'. What should puppet report now?
Needs remount.
> Is the �options� property
> insync now?
There are two properties, fstab-options and mount-state options. The
former is in sync.
I'm not sure this is easily implemented in a puppet type/provider.
> If not, what is its current value? ro or rw? What if its the
> other way around? Wrong entry in fstab but correctly mounted?
Then fstab needs changing, no remount necessary.
Apart from that, I still agree with splitting being the saner choice and
second the notion that things that share names and properties can be
wrapped up on the DSL level, and shouldn't share actual types instead.
Regards,
Felix
Forrie
Having said that, I think mingling the setting in there with the two
basic types would be essential to keep this simple. All the heavy
lifting should go on automatically in the background. A sysadmin
should only have to change the mount to "rw" or "ro" and have Puppet
do the right thing. As difficult as that may be to implement :-)
> > TL;DR Themountprovider has used a mish-mash of checkingfstaband
> > actualmountstate to determine state. A possible solution we're
> > (or /etc/filesystem on other OSes), and one that manages actualmount
> > state.
>
> [Details elided]
>
> Two separate types is the obviously correct way. Just like we
> have two separate types for specifying whether a service should
> be started at boot and for whether it should be running right
> now. And just like we have nine separate types for specifying
> file type, owner, group, mode, content and SElinux parameters.
>
> ...
>
> Hey wait, we don't! We only have one service type and one file
> type, with multiple properties. Maybe there is some good reason
> for having it like that. Perhaps like not requiring users to
> repeat the same things (service name; file path;mount-point and
> device) for things that very, very often go together.
>
> a bad choice.
>
> Splitting the 'ensure' parameter of themounttype into two, on
John Warburton
Creating a define to wrap the two resources is essentially option 3 then, isn't it?
+1 option 3
John
