On Mar 31, 2009, at 10:03 AM, Larry Ludwig wrote:
>
>
>> Then this 'load_data' call is equivalent to this Puppet code:
>>
>> class apache {
>> $host = "myhost.com"
>> $port = 80
>> }
>
> Interesting..
>
> Three questions about this:
> 1. Could these variables be overridden by a node variable? I assume
> no.
As currently implemented, no, but it would be easy to make it so they
could be - just don't set a given variable if it's already set.
The thing to keep in mind here is that this is a bare proof of
concept; I'm much more interested in how it should behave than how it
does.
>
> 2. What happens if the data file is missing?
Kerplow, at this point.
Really, I see there being a minimum of one, probably two, and quite
possibly more, data files per class. I'd expect any module that used
this to ship with a default data file, but then most sites would
override the data in that file with a separate data file.
Where you could get into even more data files per class is if you
wanted to provide branching on platforms or something similar.
Following our previous apache class, you could have:
data/apache.yaml
data/apache-debian.yaml
data/apache-rhel.yaml
...
I don't love this, but it can make some things easier. It could
especially help in calculating whether a given module supports a given
platform. Although, of course, you'd almost definitely still need
some per-platform modifications in a module (e.g., when you need to
install two packages instead of one).
Most likely, this should be done as a search path - don't hard code
that you're looking for operating system, but allow a module to
specify that it should search os, os version, then hardware;
basically, any fact or series of facts.
>
> 3. Could their be optional and mandatory variables?
Well, at this point your module would need to handle that; all this
function does is load data.
This clearly points to being able to declare, discover, and define
class attributes, so you'd think that it would have something like
that. But I'd say that's getting pretty far ahead of ourselves at
this point.
>
> This solves variables but does not solve the other issue I mention
> about files or templates that are custom per site install.
I think you've convinced that a given module should search all of the
module path directories, rather than just the first found directory.
This would allow you to have your site module dir in front of the dist
module dir and override templates or files just by putting them in the
earlier path.
>> 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.
>
> hmm is there cases were you wouldn't want the data to load?
Me? No. Someone? Assuredly. Will I support that? I highly doubt
it. Variety is the spice of thousands of filed bugs.
--
It is curious that physical courage should be so common in the world and
moral courage so rare. -- Mark Twain
---------------------------------------------------------------------
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
-~----------~----~----~----~------~----~------~--~---
