Puppet users - Jun 2007 - DesignPatterns part 2: humane class names with namespaces

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

Dear list!

In an effort to get feedback and spread the word, here follows the second 
article about possibilities to structure manifests. These Design Patterns are 
more general than the typical Puppet Recipie and will receive a own page on 
the wiki when I collect enough[1] material.


To the meat: humane class names with namespaces

Class names pose the old programmer''s dilemma of needing to be as
expressive
as possible, while staying short enough to be typeable. The Puppet language 
provides namespaces by nesting classes. With this mechanism, shorter, more 
expressive class names can be formed.

First a example:

# create my default user
class david {
	user { david: ...}
	sudoer { david: permissions => NONE }

	# Allow sudo usage for this user
	class allow_sudo inherits david {
		include sudo # install sudo
		Sudoer[david] { permissions => ALL }
	}
}

On machines where I need my user, I can now say either "include 
david::allow_sudo" or "include david" depending on whether I
shall be able to
use sudo or not.

Important points to note:

* can only handle single configuration dimension
* the base class should denote a subsystem with a single noun
* the specialisations must inherit the base class
* the specialisations should be mutually exclusive[2] 
* the classes should overlap in the sense that with or without a 
specialisation, the same resources are managed (c.f. Sudoer[david])


Alternatives
===========
Classes with more degrees of freedom have to be configured by setting 
variables in the including scope (usually at node level) and by using case 
statements within.



Regards, David



[1] I''d say at least three or four patterns. Contributions welcome.
[2] What happens here?

class parent { file { "fname": ... } } 
class child_present inherits parent { File["fname"] { ensure =>
present } }
class child_absent inherits parent { File["fname"] { ensure =>
absent } }

include child_present
include child_absent


- -- 
- - hallo... wie gehts heute?
- - *hust* gut *rotz* *keuch*
- - gott sei dank kommunizieren wir über ein septisches medium ;)
 -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGhKku/Pp1N6Uzh0URAlYzAJ48kss0XqsckGseL5zaqE3GoCR0HgCgjA57
6TaXhZA20rRHBf/NFqlfdvc=dd7N
-----END PGP SIGNATURE-----

Is this a proposal, or current behavior?
Because I love it, but it isn''t working...

On 6/28/07, David Schmitt <david@schmitt.edv-bus.at>
wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Dear list!
>
> In an effort to get feedback and spread the word, here follows the second
> article about possibilities to structure manifests. These Design Patterns
are
> more general than the typical Puppet Recipie and will receive a own page on
> the wiki when I collect enough[1] material.
>
>
> To the meat: humane class names with namespaces
>
> Class names pose the old programmer''s dilemma of needing to be as
expressive
> as possible, while staying short enough to be typeable. The Puppet language
> provides namespaces by nesting classes. With this mechanism, shorter, more
> expressive class names can be formed.
>
> First a example:
>
> # create my default user
> class david {
>         user { david: ...}
>         sudoer { david: permissions => NONE }
>
>         # Allow sudo usage for this user
>         class allow_sudo inherits david {
>                 include sudo # install sudo
>                 Sudoer[david] { permissions => ALL }
>         }
> }
>
> On machines where I need my user, I can now say either "include
> david::allow_sudo" or "include david" depending on whether I
shall be able to
> use sudo or not.
>
> Important points to note:
>
> * can only handle single configuration dimension
> * the base class should denote a subsystem with a single noun
> * the specialisations must inherit the base class
> * the specialisations should be mutually exclusive[2]
> * the classes should overlap in the sense that with or without a
> specialisation, the same resources are managed (c.f. Sudoer[david])
>
>
> Alternatives
> ===========>
> Classes with more degrees of freedom have to be configured by setting
> variables in the including scope (usually at node level) and by using case
> statements within.
>
>
>
> Regards, David
>
>
>
> [1] I''d say at least three or four patterns. Contributions
welcome.
> [2] What happens here?
>
> class parent { file { "fname": ... } }
> class child_present inherits parent { File["fname"] { ensure
=> present } }
> class child_absent inherits parent { File["fname"] { ensure =>
absent } }
>
> include child_present
> include child_absent
>
>
> - --
> - - hallo... wie gehts heute?
> - - *hust* gut *rotz* *keuch*
> - - gott sei dank kommunizieren wir über ein septisches medium ;)
>  -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFGhKku/Pp1N6Uzh0URAlYzAJ48kss0XqsckGseL5zaqE3GoCR0HgCgjA57
> 6TaXhZA20rRHBf/NFqlfdvc> =dd7N
> -----END PGP SIGNATURE-----
> _______________________________________________
> Puppet-users mailing list
> Puppet-users@madstop.com
> https://mail.madstop.com/mailman/listinfo/puppet-users
>

-- 
--
Perfection is just a word I use occasionally with mustard.
--Atom Powers--

On 6/29/07, Atom Powers <atom.powers@gmail.com>
wrote:
> Is this a proposal, or current behavior?
> Because I love it, but it isn''t working...
Sorry, it is working, just not with variables. <sad>

-- 
--
Perfection is just a word I use occasionally with mustard.
--Atom Powers--