Puppet users - Dec 2007 - mount type ensure behavior

The ensure parameter for the mount type has a ''present''
option, which
will unmount the filesystem if its mounted. I was hoping that
''present''
meant to make sure it was listed in the mounts file, but to not do 
anything with it (ie. don''t unmount if mounted, and don''t
mount if
unmounted). I thought this was how the ensure => ''present''
behavior
worked in other types, although perhaps I''m mistaken about this?

From what I can tell, there doesn''t seem to be a value that allows for 
this kind of behavior. I have some encrypted filesystems that I would 
like to manage with puppet, they require manual passphrase intervention, 
so I cannot manage the actual mounting of those filesystems with puppet 
(nor do I want to), but I would like those filesystems to appear in the 
fstab and be available as a pre-requisite for various other file types.

I would like to be able to do something like this:

mount { "/crypt":
	ensure => exists;
}

file { "/crypt/secretstuff":
	ensure => directory,
	require => Mount["/crypt"];
}

if /crypt is mounted then the file type requirement is satisfied and it 
will do its things, if its not mounted then the pre-requirement 
dependency fails.

Is there a way to do this that I am overlooking, or does the mount type 
need an additional ensure behavior?	

Micah

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 07 December 2007, Micah Anderson wrote:
> The ensure parameter for the mount type has a ''present''
option, which
> will unmount the filesystem if its mounted. I was hoping that
''present''
> meant to make sure it was listed in the mounts file, but to not do
> anything with it (ie. don''t unmount if mounted, and don''t
mount if
> unmounted). I thought this was how the ensure =>
''present'' behavior
> worked in other types, although perhaps I''m mistaken about this?
>
> From what I can tell, there doesn''t seem to be a value that allows
for
> this kind of behavior. I have some encrypted filesystems that I would
> like to manage with puppet, they require manual passphrase intervention,
> so I cannot manage the actual mounting of those filesystems with puppet
> (nor do I want to), but I would like those filesystems to appear in the
> fstab and be available as a pre-requisite for various other file types.
>
> I would like to be able to do something like this:
>
> mount { "/crypt":
> 	ensure => exists;
> }
>
> file { "/crypt/secretstuff":
> 	ensure => directory,
> 	require => Mount["/crypt"];
> }
>
> if /crypt is mounted then the file type requirement is satisfied and it
> will do its things, if its not mounted then the pre-requirement
> dependency fails.
>
> Is there a way to do this that I am overlooking, or does the mount type
> need an additional ensure behavior?
This problem is already reported in 

http://reductivelabs.com/trac/puppet/ticket/294 and
http://reductivelabs.com/trac/puppet/ticket/635

The bigger picture of this problem is discussed in the enhancement 
request "Convert ''ensure'' to use a state machine":
http://reductivelabs.com/trac/puppet/ticket/625



Regards, DavidS
- -- 
The primary freedom of open source is not the freedom from cost, but the free-
dom to shape software to do what you want. This freedom is /never/ exercised
without cost, but is available /at all/ only by accepting the very different
costs associated with open source, costs not in money, but in time and effort.
- -- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHWlq3/Pp1N6Uzh0URAoLNAKCazp1FESCdXL7IGmOad/qGhYgvjwCeP5dw
3FJrtKHRfs4BYWvU3ye6uyI=P5Hq
-----END PGP SIGNATURE-----

On Dec 7, 2007, at 4:35 PM, Micah Anderson wrote:
>
> The ensure parameter for the mount type has a ''present''
option, which
> will unmount the filesystem if its mounted. I was hoping that  
> ''present''
> meant to make sure it was listed in the mounts file, but to not do
> anything with it (ie. don''t unmount if mounted, and don''t
mount if
> unmounted). I thought this was how the ensure =>
''present'' behavior
> worked in other types, although perhaps I''m mistaken about this?
>
> From what I can tell, there doesn''t seem to be a value that allows
for
> this kind of behavior. I have some encrypted filesystems that I would
> like to manage with puppet, they require manual passphrase  
> intervention,
> so I cannot manage the actual mounting of those filesystems with  
> puppet
> (nor do I want to), but I would like those filesystems to appear in  
> the
> fstab and be available as a pre-requisite for various other file  
> types.
Yeah, I suppose this would require another value for ''ensure'';
can
you think of a reasonable name for that value?

David is right that this is related to the idea of using a real state  
machine, but it''s also that you want some values to be exclusive  
(either present or mounted) but others to be inclusive (this new  
value would match whether it was present or mounted, but would create  
yet not mount it if it were absent).

  --
  Silence is a text easy to misread.
      -- A. A. Attanasio, ''The Eagle and the Sword''
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[since this got pretty technical, I CC -dev]

On Saturday 08 December 2007, Luke Kanies wrote:
> On Dec 7, 2007, at 4:35 PM, Micah Anderson wrote:
> > The ensure parameter for the mount type has a
''present'' option, which
> > will unmount the filesystem if its mounted. I was hoping that
> > ''present''
> > meant to make sure it was listed in the mounts file, but to not do
> > anything with it (ie. don''t unmount if mounted, and
don''t mount if
> > unmounted). I thought this was how the ensure =>
''present'' behavior
> > worked in other types, although perhaps I''m mistaken about
this?
> >
> > From what I can tell, there doesn''t seem to be a value that
allows for
> > this kind of behavior. I have some encrypted filesystems that I would
> > like to manage with puppet, they require manual passphrase
> > intervention,
> > so I cannot manage the actual mounting of those filesystems with
> > puppet
> > (nor do I want to), but I would like those filesystems to appear in
> > the
> > fstab and be available as a pre-requisite for various other file
> > types.
>
> Yeah, I suppose this would require another value for
''ensure''; can
> you think of a reasonable name for that value?
>
> David is right that this is related to the idea of using a real state
> machine, but it''s also that you want some values to be exclusive
> (either present or mounted) but others to be inclusive (this new
> value would match whether it was present or mounted, but would create
> yet not mount it if it were absent).
My intuition yells "globbing" at me. This is a widely applicable
concept. As I
wrote in #625 my belief is that a way forward would be to model the 
underlying fundamental Resources (fstab entry, actual mount, [mount 
directory]) as seperate components and "export" a aggregate as Native
Type.

This enables declarative modelling of the type at a very high level. The 
theory of state machines is very mature and contains methods of combining 
multiple state machines into bigger systems. To expound a bit on the example 
in #625:

# The basic structure of a atomic resource
fstab_entry = {
        # The possible states of this resource
	:states => { 
		# This entry doesn''t exist
		:absent => { 
			:unless_cmd => "grep ''^#{name}'' /etc/fstab"
		},
		# This entry does exist
		:present => {
			:if_cmd => "grep ''^#{name}'' /etc/fstab"
		},
		# This state is only reached when a :ops fails and is used to propagate
		# failure down the dependency chain
		:failed => {}
	},
	# which possible transformations this resource accepts
	:ops => {
		# ":add"-ing the resource means it goes :from :absent 
		# :to :present by calling the :proc "some_file_manip"
		:add => {
			:from => :absent,
			:to => :present,
			:proc => some_file_manip
		}
		# ":deleting"-ing the resource means it goes :from :present
		# :to :absent by calling the :proc "some_other_file_manip"
		:delete => {
			:from => :present,
			:to => :absent,
			:proc => some_other_file_manip
		}
	}
}

This already provides the possiblity for internal consistency checks like
"is
the fstab_entry really :present after :add-ing it?

# abbrevating here
kernel_mount = {
	:states => { :mounted, :unmounted, :stuck, :failed },
	:ops => { :mount => {
			:from => :unmounted,
			:to => :mounted,
			:cmd => ...
		},
		:unmount => {
			:from => :mounted,
			:to => :unmounted,
			:on_error => :stuck,
			:cmd => ...
		},
		:force_unmount => {
			:from => :stuck,
			:to => :unmounted,
			:cmd => "umount -f ..."
		}
	}
}

Given now some magic that creates appropriate structures from these models, 
they could be combined into something like this:

mount = {
	:states => {
		# due to the info of the aggregated states it is easily possible to 
		# automatically determin which of the "combined_states" a resource
is in
		:mounted => combined_state(fstab_entry.present, kernel_mount.mounted),
		:present => combined_state(fstab_entry.present, kernel_mount.unmounted),
		:absent => combined_state(fstab_entry.absent, kernel_mount.unmounted),
		# This state demonstrates the possiblity of fallback states, which 
		# could not be detected, but be easily reachable, possibly without 
		# a :ops application. This special case is better served by exposing
		# the fstab_entry type though.
		:only_manage_fstab => combined_state(fstab_entry.present,
					kernel_mount.any_state),
	}
	# unless there are special :ops, they too can be inferred from the 
	# combined_states.
}

This mechanisms could be used at the interface to Providers too: The Type 
supplies :states and different Providers provider different :ops and 
detection routines, possibly avoiding provider specific impossible states, 
e.g. by marking them explicitely as :invalid, which can be (ab-)used for 
automatic reference generation.

Going that way leads me naturally to thinking about how to model components 
containing more resources as state machines. While the dependency system 
works good for many things, a recent faq is "how to let all Packages<|
provider == apt |> depend on a up-to-date apt cache?" and perhaps even 
worse: "why do i have to run puppetd twice to get a provider working, when 
the first run correctly configures the Resources needed for the provider?" 
Both of which have this "better state management leads to improved 
reflectivity" feeling to them. But perhaps I''m biased currently. 

The obvious problem solving these questions at the provider level is to bring 
a user-defined state ("apt cache hot", "certain resources
installed in a
certain way") back into the state machine. A way would be to define kind 
of "blessed classes" which can be used for this:

# some.pp
class puppet::apt::config {
	# Configure apt according to this site''s policies
	# run apt-get update
}

# in the definition of the apt provider:
states.map! { |s| combined_state ( s, 
Puppet::Type::Class["puppet::apt::config"].applied ) }



Voila! Of course, this means that no Package in the puppet::apt_config class 
can use the apt provider, because that would be detected as the 
combined_state("package X''s current state", 
Class["puppet::apt::config"].not_applied) which is undefined. But
that''s only
making explicit what the configuration claims: That apt cannot be used before 
its configuration is applied


This got a bit longer than planned, I hope I could get the advantages of state 
based resource modelling across.


Regards, DavidS
- -- 
The primary freedom of open source is not the freedom from cost, but the free-
dom to shape software to do what you want. This freedom is /never/ exercised
without cost, but is available /at all/ only by accepting the very different
costs associated with open source, costs not in money, but in time and effort.
- -- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHWxR7/Pp1N6Uzh0URAqjaAJoDpoSpA3mPyCiFvF2qzu6srWRTEQCfSzkM
E7jwJNpkgbZlLjoYtBxsuzM=wyPC
-----END PGP SIGNATURE-----