On Jun 9, 2010, at 12:26 PM, Ohad Levy wrote:
Sorry, this came out completely wrong, from my personal point of
view,
please integrate extlookup.
On Wed, Jun 9, 2010 at 11:59 PM, R.I.Pienaar < [email protected] > wrote:
----- "Ohad Levy" < [email protected] > wrote:
Not that I want to fight over which versions gets in, but my
implementation already supports yaml and module lookup (based on the
client environment).
you mean the commit you did just 10 minutes ago?
http://github.com/ohadlevy/puppet-lookup/commits/master
I really do not have time for games, please take whatever code you
want, I have better things to do.
cheers,
Ohad
On Wed, Jun 9, 2010 at 11:36 PM, R.I.Pienaar < [email protected] >
wrote:
----- "Luke Kanies" < [email protected] > wrote:
On Jun 9, 2010, at 11:12 AM, R.I.Pienaar wrote:
----- "Luke Kanies" < [email protected] > wrote:
On Jun 9, 2010, at 10:59 AM, R.I.Pienaar wrote:
----- "Luke Kanies" < [email protected] > wrote:
On Jun 9, 2010, at 10:44 AM, R.I.Pienaar wrote:
I think a big part of what we're interested in that Ohad
has
is
the
yaml support, rather than CSV.
It really is no challenge to get extlookup to speak yaml,
people
have it speaking to all sorts of sources even ldap.
What would be useful is instead of randomly going picking
implementations if you can say what you want to change and I
can
look at doing that.
Sorry, I didn't think I was randomly picking implementations
-
I
thought I was picking a slightly modified version that
already
supported YAML.
It's easy - I basically just want default support for YAML.
isnt right if you're going to merge it. Can you think of a
quick
easy way to improve that?
What is the global variable problem, again?
configuring the search order and behavior of the tools is
done
with
a variable in site.pp, which feels very hacky to me.
Seems like adding a setting for them is the appropriate
choice,
right?
Yeah, though being in site.pp it also means they can differ
per
environment. Here's an example:
$extlookup_datadir = "/etc/puppet/manifests/extdata"
$extlookup_precedence = ["%{fqdn}", "foo_%{foo}", "location_%
{location}", "domain_%{domain}", "country_%{country}",
"common"]
puppet.conf supports environments just fine, right?
yes, just saying, this should be environment aware if we do it.
so issues are:
- they are global variables puppet.conf under the environments
would
be great
- they have these weird %{varname} notation, I believe the
need
for
that is fixed in recent puppets but there was some parsing
order
weirdness back in the day.
The, possibly sucky, thing is that those variables like %{foo}
would be within the context of the scope the extlookup() call
is
done in,
class a {
$foo = "bar"
extlookup("test")
}
class a {
$foo = "blah"
extlookup("test")
}
Isn't going to give you the same answer if you have matching
data
files, i dont know if we can retain this behavior, make these
settings AND get rid of the strange variable notation.
The easy answer is no. If you switch to settings, dynamic
scoping
is
gone, but I'm happy at that.
hmm, so how would settings potentially look, how would we
reference
a fact etc in the puppet.conf?
in extlookup essentially I pull out %{...} and just do
lookupvar("...") and search replace it in there, I can keep
doing
this they are just tokens for search and replace. It just doesnt
seem overly puppet like to me, introducing fancy new variable
rules
but thats the best I could do in the context of a parser
function.
Really I am looking for a way to improve on this.
Yeah, I don't have much of an answer here. Settings don't support
interpolation outside of settings. You could hack something for
extlookup to use -- e.g., interpolating %foo as a variable in the
yeah, exactly what I do now.
OK, well then I guess if you dont find that syntax too offensive
then
its fine, I'll have a play with yaml support.
--
You received this message because you are subscribed to the Google
Groups "Puppet Developers" 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-dev?hl=en .
--
You received this message because you are subscribed to the Google
Groups "Puppet Developers" 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-dev?hl=en .
--
R.I.Pienaar
--
You received this message because you are subscribed to the Google
Groups "Puppet Developers" 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-dev?hl=en .
--
You received this message because you are subscribed to the Google
Groups "Puppet Developers" 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-dev?hl=en .
--
Sapolsky's First Law:
Think logically, but orthogonally.
---------------------------------------------------------------------
Luke Kanies -|- http://puppetlabs.com -|- +1(615)594-8199
--
You received this message because you are subscribed to the Google
Groups "Puppet Developers" 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-dev?hl=en.
