Re: [Puppet Users] RFC: Refactoring the mount provider.

2011-04-19 Thread John Warburton
On 23 March 2011 10:21, Nigel Kersten ni...@puppetlabs.com wrote: On Tue, Mar 22, 2011 at 4:05 PM, Stefan Schulte stefan.schu...@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

Re: [Puppet Users] RFC: Refactoring the mount provider.

2011-03-23 Thread Felix Frank
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

Re: [Puppet Users] RFC: Refactoring the mount provider.

2011-03-22 Thread Thomas Bellman
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

Re: [Puppet Users] RFC: Refactoring the mount provider.

2011-03-22 Thread Stefan Schulte
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

Re: [Puppet Users] RFC: Refactoring the mount provider.

2011-03-22 Thread Nigel Kersten
On Tue, Mar 22, 2011 at 4:05 PM, Stefan Schulte stefan.schu...@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

Re: [Puppet Users] RFC: Refactoring the mount provider.

2011-03-19 Thread 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).

Re: [Puppet Users] RFC: Refactoring the mount provider.

2011-03-18 Thread Christian Kauhaus
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

[Puppet Users] RFC: Refactoring the mount provider.

2011-03-17 Thread Nigel Kersten
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