+1 for this, it opens up quite a lot of new options.
I'm currently considering using it in a similar manner you use multiple
sources for a file resource, allowing each module who uses a variable to
lookup a data file in another module (which would solve the variable
inheritance problem), e.g.:
I have an apache module, and I have location A and location B modules.
Apache module would lookup in location A module for data file if the
manifest is running on location A, if it cant find any definition it would
fall back to some other defaults (which are then defined in the apache
module data file)
Thanks for sharing!
Ohad
On Tue, Mar 31, 2009 at 10:38 AM, Luke Kanies <l...@madstop.com> wrote:
> Hi all,
>
> We at Reductive Labs keep running into clients who need something like
> an attribute class - that is, for a given module, they want a single
> class that handles all of the variable setting and overriding, and
> then they want that attribute class to be merged into all or some of
> the classes in the module. (Teyo has especially been pushing me to
> solve this problem.)
>
> This looks a lot like composition, which Puppet doesn't currently
> support - you include one class's behaviour in another, rather than
> inheriting. This lack of composition is, I think, partially why
> people keep trying to do variable inheritance and getting frustrated
> that it doesn't work well.
>
> While doing a code audit for a client this week, though, I found their
> solution to this problem to be close enough that I was able to take it
> almost the rest of the of way. They had what amounts to a 'data'
> module with a class for each class that needed external data, and then
> they defined all of the attributes in that data class. That is, if
> you have an 'apache' class, you'd also have a 'data::apache' class
> with a bunch of attributes. Then all of your usage of those
> attributes would say '$data::apache::variable'.
>
> The big benefit of this model for them is that it allows clean change
> control of all of the important configuration data (as opposed to
> manifest structure and resources), and, again, it looks a lot like
> composition. In their case, they branch this module for all of their
> environments, but none of the other modules.
>
> As soon as I saw it, though, I thought of a way that might make it
> better, so I wrote a function that enables that way (and a converter
> for their existing data).
>
> Basically, I created (and have attached) a simple function that knows
> how to find and load a yaml file from a data directory, and it loads
> that file as a hash of parameters that should be set as local
> variables in the class.
>
> For instance, say you have this class apache; you'd create this file:
>
> data/apache.yaml
>
> And put all of the attributes you care about in that file.
>
> Then, in your apache class, you'd say:
>
> class apache {
> load_data()
> ...
> }
>
> It would pick the right file based on the class name (although the
> current function allows you to specify the class, also), load it, and
> set all of the contained attributes as local variables in the class.
> So, if your apache.yaml file looks like this:
>
> ---
> host: myhost.com
> port: 80
>
> Then this 'load_data' call is equivalent to this Puppet code:
>
> class apache {
> $host = "myhost.com"
> $port = 80
> }
>
> The function is currently set up to support one big 'data' directory
> for all of your modules. One could argue that it should instead
> support a data file per module, but the benefit of this one big data
> directory is that it makes it *much* easier to write sharable modules
> - you extract all of your site-specific data into this data dir, and
> you share the module with essentially no site data. It's probably
> most reasonable to support an in-module data file and a site-wide data
> directory to make it easy to provide defaults.
>
> I'm beginning to think that this, or a function a lot like this,
> should be included directly into Puppet, and data should get loaded
> automatically, rather than requiring the call to the 'load_data'
> function.
>
> What do you think?
>
> --
> Fallacies do not cease to be fallacies because they become fashions.
> --G. K. Chesterton
> ---------------------------------------------------------------------
> Luke Kanies | http://reductivelabs.com | http://madstop.com
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
