http://projects.puppetlabs.com/issues/6309#note-11 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 -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Christian Kauhaus
2011-Mar-18 10:21 UTC
Re: [Puppet Users] RFC: Refactoring the mount provider.
Am 17.03.2011 18:40, schrieb Nigel Kersten:> 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 <>< · kc@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 -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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 -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Thomas Bellman
2011-Mar-22 20:19 UTC
Re: [Puppet Users] RFC: Refactoring the mount provider.
Nigel Kersten wrote:> 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 -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Stefan Schulte
2011-Mar-22 23:05 UTC
Re: [Puppet Users] RFC: Refactoring the mount provider.
On Tue, Mar 22, 2011 at 09:19:16PM +0100, Thomas Bellman wrote:> Nigel Kersten wrote: > > > 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.)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
2011-Mar-22 23:21 UTC
Re: [Puppet Users] RFC: Refactoring the mount provider.
On Tue, Mar 22, 2011 at 4:05 PM, Stefan Schulte <stefan.schulte@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. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Hi, I don''t see the problems, really.> 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 -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
+1 here for this. 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 :-) On Mar 22, 4:19 pm, Thomas Bellman <bell...@nsc.liu.se> wrote:> Nigel Kersten wrote: > > TL;DR Themountprovider has used a mish-mash of checkingfstaband > > actualmountstate 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 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. > > So, no, I think splitting themounttype into two types would be > a bad choice. > > Splitting the ''ensure'' parameter of themounttype 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-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
John Warburton
2011-Apr-20 01:53 UTC
Re: [Puppet Users] RFC: Refactoring the mount provider.
On 23 March 2011 10:21, Nigel Kersten <nigel@puppetlabs.com> wrote:> On Tue, Mar 22, 2011 at 4:05 PM, Stefan Schulte > <stefan.schulte@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. >Creating a define to wrap the two resources is essentially option 3 then, isn''t it? +1 option 3 John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Martin Alfke
2011-Apr-20 06:13 UTC
Re: [Puppet Users] Re: RFC: Refactoring the mount provider.
+1 for using one resource type with different parameters. On 04/19/2011 10:22 PM, Forrie wrote:> +1 here for this. > > 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 :-) > > > > On Mar 22, 4:19 pm, Thomas Bellman <bell...@nsc.liu.se> wrote: >> Nigel Kersten wrote: >>> TL;DR Themountprovider has used a mish-mash of checkingfstaband >>> actualmountstate 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 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. >> >> So, no, I think splitting themounttype into two types would be >> a bad choice. >> >> Splitting the ''ensure'' parameter of themounttype 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 >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.