Issue #2953 has been updated by R.I. Pienaar aka Volcane.
> 1) Should we load data per class or per-variable?
>
> Luke's data loading function is per-class, basically setting variables in the
> class's scope, but Volcane's extlookup is per-variable. A nice middle-ground
> might be static declaration of the variables that should be loaded; something
> like:
> [...]
I like things to be explicit, fnction has the benefit of being obvious. If we
are introducing syntax like this that will make it obvious which is why i am
favoring this over blow.
> 2) Should we just automatically load data, or should we introduce something
> like a new syntax that triggers loading?
>
> See above, but I have also considered use of a slightly modified variable
> reference syntax; e.g., an unlikely possibility:
> [...]
automatic loading based on syntax in one might be a good place to be.
> 3) What kind of flexibility should the back-end support for search paths and
> overriding data?
>
> The whole goal of this is to support search paths through different data
> sources
> and to allow overriding of data. E.g., my dnsresolver class needs to allow
> users
> to customize the data so that each site can define how to pick its resolvers.
>
> The class/module developer can't know in advance how data should be resolved
> -
> each site should be able to define different search paths.
>
> I think this is actually the hardest part, and all I can think of is that the
> data backend
> itself needs to be able to define the search path, so whomever fills in the
> data also gets to pick the search path.
I agree, obviously, since thats how extlookup works, though the manifest define
the search order which was the simplest way to hook the configurability into
puppet with a function.
there's a few other things extlookup does that I think should be kept in mind:
In the data i can do:
- ntpservers,%{country}.pool.ntp.org
this will use lookupvar and fetch $country and put it in there, weird variable
syntax due to it being a function and I need to parse it, if you impliment
something proper this should be better but the functionality should be there as
it's extremely useful
- you can specify defaults:
$foo = extlookup("critical_mailq", 10)
easily replicated in your first suggested syntax by providing the ability to
assign defaults
- overridable searching
in a manifest i can do:
$foo = extlookup("apache_package", "httpd", $operatingsystem)
this will push a search for operatingsystem first into the search order - in
extlookup that looks in lets say debian.csv first before doing whats globally
configured. Works a charm to create a map between differences in OS
> Volcane's extlookup:
> http://nephilim.ml.org/~rip/puppet/extlookup.rb
Also http://www.devco.net/archives/2009/08/31/complex_data_and_puppet.php
----------------------------------------
Feature #2953: Puppet should support a data loading system
http://projects.reductivelabs.com/issues/2953
Author: Luke Kanies
Status: Accepted
Priority: Normal
Assigned to:
Category: plumbing
Target version: Rowlf
Affected version: 0.25.1
Keywords: data, loading, external, search
Branch:
Similar to R.I.Pienaar's extlookup functionality, along with the data loading
function I've written, Puppet should support a builtin system for loading class
data from external sources.
When used as a function, this is relatively simple, because the class developer
has to trigger the data loading. When used as a subsystem, Puppet should be
able to trigger the loading on its own, which means it's a bit more complicated.
I see a few questions that should be resolved:
1) Should we load data per class or per-variable?
Luke's data loading function is per-class, basically setting variables in the
class's scope, but Volcane's extlookup is per-variable. A nice middle-ground
might be static declaration of the variables that should be loaded; something
like:
<pre>
class foo loads($var1, $var2) { ... }
</pre>
2) Should we just automatically load data, or should we introduce something
like a new syntax that triggers loading?
See above, but I have also considered use of a slightly modified variable
reference syntax; e.g., an unlikely possibility:
<pre>
class foo {
file { $$var: # loaded variable
...
}
}
</pre>
3) What kind of flexibility should the back-end support for search paths and
overriding data?
The whole goal of this is to support search paths through different data
sources and to allow overriding of data. E.g., my dnsresolver class needs to
allow users to customize the data so that each site can define how to pick its
resolvers. The class/module developer can't know in advance how data should be
resolved - each site should be able to define different search paths.
I think this is actually the hardest part, and all I can think of is that the
data backend itself needs to be able to define the search path, so whomever
fills in the data also gets to pick the search path.
Assigning to rowlf, but it's unlikely to make it in.
Luke's data loading thread:
http://groups.google.com/group/puppet-users/browse_thread/thread/b439cd34803ed5a1
Volcane's extlookup:
http://nephilim.ml.org/~rip/puppet/extlookup.rb
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://reductivelabs.com/redmine/my/account
--
You received this message because you are subscribed to the Google Groups
"Puppet Bugs" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
